不含SFU的多党制WebRTC

Question

基于这篇文章，在没有服务器的情况下实现WebRTC解决方案时，我假设它意味着SFU，瓶颈是只有4-6个参与者可以工作。

有什么解决办法可以解决这个问题吗？例如，我只想使用Firebase作为唯一的后端，主要是信令和没有SFU。实现至少25-50名WebRTC参与者的总体实施战略是什么？

更新：这个Github项目共享一个不同的语句。它说：“一个完整的网格对多达100个连接是伟大的”

Answer 1

MESH的真正瓶颈是每个RTCPeerConnection都会在浏览器中执行自己的视频编码。

p2p的概念自然包括两个对等点都应该根据网络条件调整编码质量的要求。因此，当浏览器向对等点X (良好的下载速度)和Y(坏的下载速度)发送两个流时，X和Y的编码将有所不同-Y的帧数和比特率将低于X。

听起来很合理，对吧？但不幸的是，要求为每个对等连接分别编码视频。

如果多个对等连接可以重复使用相同的视频编码，则MESH将更加可行。但谷歌并没有在浏览器中提供这个选项。同步广播需要SFU所以这不是你的情况。

那么，浏览器可以在一台典型的机器上执行多少个并行视频编码，720p30fps视频? 5-6，而不是更多。640x480 15 fps？可能是20个编码。

在我看来，在WebRTC设计中，编码层和网络层可以分开，甚至getUserMedia也可以扩展到getEncodedUserMedia，这样就可以向多个对等点发送相同的编码内容。

这就是人们使用SFU进行多点WebRTC的真正实际原因。

Answer 2

如果你想和25个人开一个会议，所有的人都发送他们的视频，那么一个常规的webrtc设置将无法工作。除非你大幅降低你的视频质量。这样做的原因是，每个参与者都需要向每个其他客户端发送24条不同的流。因此，假设您的流是128 KB/s，那么您需要有3MB/s的上传速度可用。但这并不总是可用的。然后也下载同样的数量。

问题是，这是不可伸缩的。这就是为什么你需要一个SFU。然后，您将只发送一个流，并从其他人接收。SFU的另一个优点是，您可以使用同步广播，它根据网络速度调整接收到的流的质量。

例如，可以使用Janus网关或mediasoup。下面是一个已经安装的媒体视频会议应用程序，它是可伸缩的github储存库