一通WebRTC通话中能容下多少用户（一）

作者：Tsahi Levent-Levi（原文连接）

翻译：刘通

原标题：How Many Users Can Fit in a WebRTC Call?

你被要求做一个群组视频通话，显然，你应该为该项目选择WebRTC技术。它几乎是唯一的选择，当然也是性价比最高的选择。但是其中有一个很大的问题：我们可以将多少用户同时放进一个WebRTC组通话中。

每周至少会有一个人问我点到点的WebRTC能否用于大型组通话，因为怀疑这种技术可能不适用于这种用例。但是，WebRTC可以适应跟大的群组通话。

你需要将WebRTC视为你认为合适的一组技术积木块，并且WebRTC的浏览器实现只是其中的一块积木。

WebRTC中支持群组视频通话的最常用构件是SFU（Selective Forwarding Unit选择性转发单元）。一个媒体路由器，它接收来自会话中所有参与者的媒体流，并决定将该媒体路由到哪个人。

我在本文中想要做的是回顾在尝试使用WebRTC创建支持大型群组视频会话的应用程序时需要采取的一些方面和决策。

分析复杂性

我们今天需要做的第一步是分析我们用例的复杂性。

通过WebRTC和一般的实时视频通信，我们将全部归结为速度和反馈：

1. 速度—我们期待的分辨率和比特率

2. 反馈—单个会话的流数量

让我们从一个例子开始。

假设你想为企业运行一个群组通话服务，而且是全球范围运行的。人们将一起参加工作会议。你计划将小组会议限制为4个人。我知道你想要往里加更多的人，我会试图让这件事情变得简单。

上面的插图展示了有4个参与者的会话是什么样的。

720p

你想要高质量的视频。这也是每个人想要的。因此，你计划让所有参与者发送720p的视频分辨率，针对WQHD监视器（即2580×1440）。假如说这会有1.5Mbps（这里我还是保守的，可能会需要更多），所以：

# 会话中的每个参与者要发送1.5Mbps并接受3个1.5Mbps的流。

# 4个参与者，媒体服务器需要接收6Mbps并发送18Mbps。

总结在一张简单的表格中，我们就会有：

VGA

如果您对分辨率不感兴趣，则可以瞄准VGA分辨率，甚至将比特率限制为600Kbps：

在进行VGA时，你可能想要避免的事情是需要在显示器上提高分辨率—它可能看起来很难看，特别是在较大的4K显示器上。

根据原始数据的粗略计算，你可以简单的认为1个720p会话的代价等同于3个VGA会话的代价。

Hangouts的类型

但是如果我们的布局有些不同呢？主要讲话者的画面比较大，其他参与者的画面比较小：

我之所以称之为Hangouts类型，是因为Google Hangouts以这种布局而闻名，并且是第一个专门使用它而不提供更多其他布局的应用之一。

这种情况，我们将使用同时联播（simulcast），并计划让每个人都输出高质量的视频，SFU决定使用哪个输入流作为主导讲话方，为其提供更高的分辨率，其他选择较低分辨率。

你会把720p定为目标，因为经过几次实验后，你发现放大到较大画面的低分辨率看起来不太好，你最终会得到这个：

# 会话中的每个参与者发送2.2Mbps（对于720p的流是1.5Mbps，对于其他将与之联播的分辨率视频提供额外的80Kbps）

# 会话中的每个参与者从主要发言者接收到1.5Mbps的数据，并未较小的视频窗口接收另外两个大约300Kbps的输入数据流

# 在4名参与者中，媒体服务器需要接收8.8Mbps并发送8.4Mbps

目前为止，我们学到的是：

具有相同用户数量的群组视频的不同用例在媒体服务器上会转换为不同的工作负载。

如果没有具体要求的话，联播的效果很好，并且可以提高群组通话的有效性和质量（联播也就是我们在Hangouts类型会议中讨论的）。

在我们描述的用于4路视频通话的3种场景中，我们在SFU中获得了这些活动：

给你留一个作业—现在假设我们想要做一个双向会话，通过WebRTC向100人播放。现在要计算你在服务器端需要的流和带宽数量。