无 SFU 的多方 WebRTC答案

【问题标题】：Multi-party WebRTC without SFU无 SFU 的多方 WebRTC
【发布时间】：2020-09-15 03:57:56
【问题描述】：

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

有没有可以解决这个问题的解决方案？例如，我只想使用 Firebase 作为唯一的后端，主要是信令，没有 SFU。在 WebRTC 中实现至少 25-50 名参与者的一般实施策略是什么？

更新：此Github project 分享了不同的声明。它指出“一个完整的网格非常适合多达 100 个连接”

【问题讨论】：

使用 webrtc 你总是需要一个服务器。常规 webrtc 将其视频点对点发送，并且需要一个服务器来发送信号。使用 SFU，所有媒体发送都由服务器处理。 MCU 也一样
顺便说一下，100 个连接并不意味着 100 个参与者。在网格中，每个人都与其他人相连。如果有N个用户，那么连接数大约是N^2。所以 100 个连接实际上意味着 10 个参与者

标签： firebase webrtc

【解决方案1】：

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

p2p 概念自然包括要求双方都应根据网络状况调整编码质量。因此，当您的浏览器向对等点 X（下载速度快）和 Y（下载速度差）发送两个流时，X 和 Y 的编码将不同 - Y 将接收比 X 更低的帧率和比特率。

听起来很合理，对吧？但是，不幸的是，要求对每个对等连接进行单独的视频编码。

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

那么，对于 720p 30 fps 视频，浏览器可以在一台典型机器上执行多少并发视频编码？ 5-6，不多。对于 640x480 15 fps？可能有 20 种编码。

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

这就是人们将 SFU 用于多点 WebRTC 的真正实际原因。

【讨论】：

所以解决的办法是降低编码帧大小以实现更多参与者
是的。而且我猜如果你只做音频，MESH 应该完全可以容纳 200 名参与者。
我一次进行了 50 个并发实时 Opus 编码，只占用了 30% 的 CPU，所以，我想，在一台强大的机器上应该可以使用 200 个
@user1390208 当您完成 50 次作品编码时。这是否意味着音频会议中有 7 个人？因为每个人都有 1 个传出和 6 个接收，所以 7*7 连接。是这样的配置吗？
@quarks 是的，我的意思是 200 名参与者。您将发送 200 个流（准确地说是 199 个），因此您将执行 199 个 Opus 编码。您将收到来自其他同行的 199 个流，您的浏览器将进行 199 个 Opus 解码。在 8 核 I7 机器上应该没问题。

【解决方案2】：

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

问题在于它不可扩展。这就是您需要 SFU 的原因。然后你将只发送一个流并从其他人那里接收。 SFU 的另一个优点是您可以使用联播，它可以根据您的网络速度调整接收到的流的质量。

例如，您可以使用 Janus 网关或 mediasoup。这是一个已经设置好的可扩展的 mediasoup 视频会议应用程序github repository

【讨论】：

一个有趣的演示应用程序将尝试它。问题是，如果只有音频，那么 200 名参与者或至少 100 名参与者是否可以使用全网状网络？没有服务器？如果演示者的一个视频和每个人都只是在观看，那么对于一个 50 人参加的会议来说，对于 500kbps 流的主持人来说，上传速度约为 25Mbps？
@quarks 还阅读了我在您最初的问题下发表的评论。使用全网状音频，说明它有 40Kbps 的 opus 编解码器，有 200 名参与者，每人将有 8Mbps 的上传。然后 100 名参与者 4Mbps。我认为通常情况下仍然可以连接良好。
@quarks 是的，确实会是 25Mbps 上传，一位主持人广播
@Dirk V 您唯一的论点是带宽。如果每个参与者都有足够的带宽，那么网格是完全可以的。在机器上编码资源通常会比带宽更快地限制您。
@user1390208 带宽可能是一个问题并没有错，我不同意你关于编码资源通常是第一个问题的说法。 webrtc视频通话限制4-6人的原因不是因为编码，而是因为带宽，我想我们可以同意这一点。现在假设您有无限带宽，那么您可以添加编码也可能成为问题。但是再次使用超级计算机，那么您将不再有问题。所以是的，你可以添加编码也可能是一个问题，不会出错