将实时网络摄像头流式传输到服务器并返回网络的最佳方式是什么？

Question

我需要一些帮助。

通过网络设置从网络摄像头到服务器并返回到多个用户的直播的最佳方式是什么？

本质上，我正在尝试创建一个可以支持许多用户的群组视频聊天应用程序。

我不希望它成为点对点 webRTC。

我实际上设法让它与 getUserMedia() -> mediaRecorder -> ondataavailable -> 通过 SOCKET.IO 将 blob 块传递到 node.js -> socket.io 将 blob 块发送回其他连接的用户 -> 将这些块附加到连接到 mediaSource 的 sourceBuffer，该 mediaSource 设置为源 URL

它确实有效！但它是如此缓慢、滞后和资源密集型。由于这些块每秒传递 20 个，因此页面速度会大大减慢。我认为你不应该这么快地将那么多 blob 传递到 sourceBuffer 。只是为了进行测试，我尝试每 3 秒保存一次 mediaRecordings（因此它不是资源密集型）并将这些 webm blob 传递到 sourceBuffer，但由于某种原因，只有第一个 webm 加载，而其他 webm 没有添加或开始播放。

这种方式不适用于生产应用程序。

执行此操作的“正确”方法是什么？

如何将视频流从网络摄像头正确传递到 Node.js 服务器？

如何将这个直播流从 Node.js 服务器传输回网络，以便我们可以进行群组视频聊天？

我有点失落。请帮忙。

我使用 HLS 吗？记录RTC？

我是通过 http 还是通过 socket.io 从 Node.js 进行流式传输？

已经有一些服务可以让您轻松做到这一点，例如 vonage video api tokbox，但这些服务似乎非常昂贵？

我想通过我自己控制的 Node.js 服务器运行视频流。

最好的方法是什么？

请帮忙。

谢谢

Answer 1

本质上，我正在尝试创建一个可以支持许多用户的群组视频聊天应用程序。

我不希望它成为点对点 webRTC。

视频聊天需要低延迟，因此需要使用WebRTC。请记住，“对等点”之一实际上可以是服务器。

它确实有效！但它是如此缓慢、滞后和资源密集型。

无论您如何做，视频编码/解码都是资源密集型的。如果“慢”和“滞后”意味着高延迟，那么是的，记录块、发送块、解码块本质上将具有更高的延迟。此外，您所描述的内容不会丢帧或动态调整编码，因此如果连接无法跟上，它只会进行缓冲，直到可以为止。这是一种与您想要的不同的权衡。

同样，对于视频聊天来说，实时性比质量和可靠性更重要。如果这意味着丢弃帧、快速重新采样音频以赶上、以低比特率编码，甚至暂时完全丢弃流几秒钟，那么这就是需要发生的事情。这就是整个 WebRTC 堆栈的作用。

由于这些块每秒传递 20 个，因此页面速度会大大减慢。我认为你不应该这么快地将那么多 blob 传递到 sourceBuffer 。

不，这不太可能是您的问题。接收端可能无法跟上解码所有这些流的速度。

我使用 HLS 吗？

不适合任何积极参与聊天的人......需要低延迟的人。对于其他人来说，是的，您可以利用 HLS 和 DASH 为您提供一种更实惠的方式，通过现有 CDN 分发流。请参阅此答案： /sf/answers/2623316041/ 基本上，仔细检查您的要求并确定是否每个人都真正参与。如果不是，请将其转移到比 WebRTC 更便宜的流媒体方法。

记录RTC？

不，这与你的项目无关，坦率地说，我不知道为什么人们继续使用这个库来做任何事。也许他们有一些我不知道的特定用例，但浏览器多年来一直内置MediaRecorder 。

已经有一些服务可以让您轻松做到这一点，例如 vonage video api tokbox，但这些服务似乎非常昂贵？

这是一件昂贵的事情。我认为您会发现，在大多数情况下，使用已经具备基础设施的现有服务比自己动手更便宜。