实施 WebRTC 群组通话时您将遇到的最大挑战是估算优化带宽使用。
视频是一种资源消耗。有人说 WebRTC 是一对一通话的绝佳解决方案，但在群组通话方面却有所欠缺。对他们来说，我会说WebRTC 是一种技术，而不是一种解决方案。在这种情况下，这仅意味着您需要付出一些努力才能使群组视频通话正常运行。
这到底是什么意思？您需要首先考虑带宽管理。
为什么？
让我们假设有一个 25 位参与者的视频通话。我们很谦虚——我们只希望每个人都以 500kbps 的速度对他的视频进行编码，如果我们计划让每个人都使用纯 VGA 分辨率（640×480 像素），这是合理的。
一起做道数学题吧：
我们最终得到12.5Mbps。这仅仅是视频，没有头文件或音频的开销。由于我们只需要接收24个参与者的媒体，我们可以将其 “四舍五入 “为12Mbps。
我确定您的下行链路高于 12Mbps，但让我告诉您一些您可能不知道的事情：
- 100Mbps的下行并不意味着你真的可以长时间获得可持续的12Mbps；
- 这也不意味着您可以获得 12Mbps 的传入UDP流量（并且您更喜欢 UDP，因为它更适合发送实时媒体）；
- 在合理的 CPU 使用率下，您的设备很可能无法解码 12Mbps 的视频内容；
- 如果你有视频解码的硬件加速，它通常仅限于 3 或 4 个媒体流，因此处理 24 个这样的流意味着软件解码——再次违反 CPU 处理限制；
- 群体越大，设备和网络连接就越多样化。所以你会有人在旧设备和智能手机上加入，或者网络连接不好。对他们来说，12Mbps 充其量只是科幻小说；
- 根据经验，我会将任何使用超过 3-4Mbps 的下行链路视频流量进行视频群组通话的服务视为未适当优化的服务。
您可以做得更好，尝试找出较低的比特率，限制您发送和接收的数量，并为视频小组会议中的每个参与者单独执行此操作。您可以考虑显示布局、主讲人和有贡献的参与者等。
这正是您在这里进行的 90% 的战斗——有效地管理带宽。
要进行群组视频通话吗？确保节省大量时间和资源用于带宽估计和管理的优化工作。哦——你需要不断地这样做。因为WebRTC 是一场马拉松而不是短跑😀
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/14710.html
