基于this article，在不使用服务器的情况下实施WebRTC解决方案时，我认为这意味着SFU，瓶颈是只有4-6名参与者可以工作。
是否有可以解决此问题的解决方案？例如，我只想将Firebase用作唯一的后端，主要是信令而不是SFU。达到至少25-50名WebRTC参与者的一般实施策略是什么？
更新：该Github project具有不同的说法。它指出“全网状结构最多可容纳约100个连接”
答案 0 :(得分：1)
您对MESH的真正瓶颈是每个RTCPeerConnection都会在浏览器中进行自己的视频编码。
p2p概念自然包括两个对等方均应根据网络条件调整编码质量的要求。因此，当您的浏览器将两个流发送到对等X（良好的下载速度）和Y（不良的下载速度）时，X和Y的编码将有所不同-Y的帧率和比特率将低于X。
听起来合理吧？但是，不幸的是，每个对等连接都要求单独的视频编码。
如果多个对等连接可以重新使用相同的视频编码，则MESH将更加可行。但是Google并未在浏览器中提供该选项。 Simulcast需要SFU，所以情况并非如此。
那么，对于720p 30 fps视频，浏览器可以在一台典型的计算机上执行多少个并发视频编码？ 5-6，不多。对于640x480 15 fps？也许有20种编码。
在我看来，WebRTC设计中可以将编码层和网络层分开，甚至可以将getUserMedia扩展为getEncodedUserMedia，以便您可以将相同的编码内容发送给多个对等端。
这是人们在多点WebRTC中使用SFU的真正实际原因。
答案 1 :(得分：0)
如果您想与25个人一起召开会议并发送视频，则常规的webrtc设置将无法正常工作。除非您大幅降低视频质量。原因是每个参与者都需要向其他每个客户端发送24个单独的流。因此，假设您的流为128 KB / s，那么您将需要3 MB / s的上传速度。并非总是可用。然后还要下载相同数量的内容。
问题是无法扩展。这就是为什么您需要一个SFU。然后，您将仅发送单个流并从其他流接收。关于SFU的另一个好处是，您可以使用同播，根据网络速度调整接收流的质量。
例如，您可以使用Janus网关或mediasoup。这是一个可扩展的github repository
可设置的mediasoup视频会议应用程序