作者：Tsahi Levent-Levi
原文：https://bloggeek.me/optimize-webrtc-performance/
编译：小及狗
WebRTC 是一场马拉松，而不是短跑。不能写一次就忘了，您需要日复一日地努力，不断改进和优化您的应用程序。
其中一部分优化是围绕 WebRTC 性能进行的。下次您需要优化 WebRTC 应用的性能时，可以验证以下 8 个方面。
1. 发送和接收更少的字节
令人惊讶的是，如果发送和接收的字节数（尤其是视频字节）更少，性能就会更高。您的设备将使用更少的网络和 CPU 资源（这将使其性能更佳）。媒体服务器需要路由的数据也会更少。
我知道我们最终想要的是尽可能清晰的 4K 分辨率和 60fps 画质。这还是在您开始梦想做 VR 或 8K 之前。
但问题是，在 5 或 6 英寸显示屏的智能手机上，真的需要 4K 甚至全高清分辨率吗？当你同时分享屏幕，而其他参与者只在乎你的屏幕显示效果而不是您的颜值时，网络摄像头的 4K 分辨率还有用吗？
👉我为什么要把字节数换成分辨率？因为比特率（= 字节数）越高，我可以在合理质量下压缩出更高的分辨率。
我们称其为分辨率阶梯。对于给定的比特率，我们会匹配一个合适的分辨率，并根据实际比特率调整阶梯的分辨率。具体数值会根据视频编解码器、帧率、内容类型以及分辨率阶梯的升降而变化，但这是后话。
另外，您无法控制阶梯上的梯级位置，这要由浏览器来决定。
所以……先做第一件事。
计算一下像素，检查一下比特率，看看它是否适合你的用例。问问自己是否可以、在哪里以及如何降低比特率。无论是在输入流还是输出流中。更简单的方法是，先关注分辨率和帧率，然后再关注比特率和字节数。
2. 使用更好的视频编解码器
在相同的比特率预算下，每种视频编解码器的质量如下：
VP8 < VP9 < AV1
AV1 的质量比 VP9 更好，而 VP9 的质量又比 VP8 更好（对于相同的比特率）。
所以选择较新的视频编解码器意味着更低的比特率。但这也意味着 CPU 和内存的使用率更高。这让决策变得不那么简单…
当您选择更好的视频编解码器时，还需要做出另一个决定——您是要利用增加的比特率来提高质量，还是要降低比特率并保持相同的质量水平？
在多视频编解码器环境中，这并不是唯一需要解决的问题。您需要根据具体情况选择合适的视频编解码器：
- AV1 是目前非常不错的编解码器。但它不适用于老款设备，尤其是在分辨率和比特率过高的情况下。
- AV1 也非常适合屏幕共享中的文本（即使在低比特率下，文本的可读性也比其他替代方案好得多）。
- H.264 在合适的设备上可以成为出色的编解码器 – 在许多情况下，它都带有硬件加速功能，这意味着更低的 CPU 使用率，并且移动手机在长时间视频通话时不会发热。
- VP8 坚如磐石，随处可用。
- HEVC(H.265) 是 Apple 为 Apple 设备开发的，可能可用，也可能不可用。
- VP9 现在是 VP8 和 AV1 之间的过渡点
您使用哪一个？
我们只需知道，优化 WebRTC 的性能意味着弄清楚在哪种场景下使用哪种视频编解码器。
3. 不要一直发送所有音频流
曾经，我的一位客户要求能够重现人山人海的球场体验。当进球时，您可以听到周围的人和观众一起欢呼。
问题除了需要 CPU 和/或网络来实现外，还在于当时谷歌的 WebRTC 实现（即 libWebRTC）并不喜欢混合过多的音频源。它只是简单地接收音量最大的 3 个传入音频流并进行混合，而忽略了所有其他音频流。
这样做的好处是什么？它减少了 CPU 负载。坦率地说，如果在一次会议中发言的人数超过 3 个，除了 WebRTC 实现之外，您还会遇到其他问题——这些问题很可能需要您自行解决。
一两年前，谷歌决定移除这项优化。现在它会混合所有传入的音频流。理论上，您现在可以让体育场的观众体验到每个人都在欢呼的声音。实际上呢？由于额外的混音工作，您的用户可能会遭受 CPU 发热加剧的困扰。
您该怎么办？
确定要混合的音频流的最大数量。如果不确定，就选择神奇的数字 3。
3 是 libWebRTC 使用了十多年的神奇数字。现在，libWebRTC 没有限制了。但是……Google Meet 仍将 3 作为它的神奇数字。
既然有了这个数字，确保在 SFU 中，发送给听众的音频流不超过 3 个。剩下的音频流怎么办？用DTX替换它们的媒体，或者干脆不发送……这取决于您和您的架构。
这将提高会话的规模，优化 WebRTC 的网络和 CPU 性能。
4. 仅在必要时使用 Simulcast 和 SVC
Simulcast 很棒！SVC 更好？
但并不是每一个问题都能用你所谓的 Simulcast（或 SVC）的锤子钉死。
以 Simulcast 为例。我们使用它来生成不同比特率的多个视频流，以便小组会议能够处理不同网络和设备的用户。这提高了与会者的平均会议用户体验。
但是……在一对一会议中完成，这只是浪费。
这里的发送方发送了太多的视频流，导致其浪费了宝贵的 CPU 和网络资源，而不是使用相同的资源来提高单个视频流的会议质量。
您需要弄清楚何时使用、何时不使用这些功能…
5. 区别对待不同的配置
上面那个关于 simulcast 的例子？我们再概括一下，好吗？
您的应用程序在运行 WebRTC 时会采有不同的配置。这可能是由于用户数量、用户位置、使用的设备、网络质量，甚至是用户在会议中的操作而导致的。
把所有这些不同的排列组合，我们称之为配置。现在，针对每一种配置，找出优化 WebRTC 堆栈性能的最佳方法。
这样的优化值得付出努力吗？
这种配置是否足够频繁？对于重要的用户/客户来说？
实现这种优化有多复杂？
从一种配置切换到另一种配置时，能否顺利打开或关闭现有的各种优化？
这一点很重要。去做吧。
6. 拥有更多媒体服务器
如果您想优化 WebRTC 应用程序的性能，不妨在这个问题上投入更多的媒体服务器。
投入更多硬件固然很好，但我想说的是，这些服务器需要离用户更近。
把所有媒体服务器都放在美国东部的一个数据中心吗？您需要增加另一个地区。
覆盖了美国和欧洲？是时候增加亚洲了。
等等。
在我的视频 API 报告中，有完整的部署范围：
从单个地区、单一大陆到 200 多个地区，应有尽有。看来您要么满足于 10-30 个地区，要么努力争取超过 200 个地区。
看看用户来自哪里。在他们周围的数据中心部署媒体服务器。
哦，其实您并不需要做得太多。很多大型供应商（他们拥有高质量的媒体）的地区覆盖范围都不超过 20 个。
7. 将用户分配到更近的服务器
服务器遍布全球？好极了！
现在您最终要把用户连接到哪里？连接到哪个地点？
如果有两个人在美国开会，一个在法国。您的媒体服务器需要覆盖哪些地区？
- 如果是在法国……那么在美国的两个人的体验会很差。尤其是当他们在会议中相互通话时（他们的媒体流跨越了大西洋）
- 如果是在美国……那么在法国的那个人可能会因为在同一大洋上的连接不佳而受到影响，最终导致比您想象的更多的数据包丢失和延迟
- 您可以级联这个功能，让多个地区的多个媒体服务器处理会话。但这需要付出努力。
我想表达的重点是：为小组会议分配媒体服务器并非易事。请花些时间弄清楚并妥善实施。
8. 收集、测量和监控指标
如果不知道哪里出了问题以及为什么会出现问题，您就无法修复、改进或优化问题。
我一开始就说过，WebRTC 是一场马拉松，而不是短跑。说到优化 WebRTC 性能，这意味着需要不断改进您的应用程序。
哪里需要改进？改进什么？
- 什么能使您的努力获得最高的投资回报率？
- 您的改变是否起到了作用，是否真正改善了情况？
- 要回答这些问题，您需要收集指标、测量和分析数据，并对其进行持续监控。
将此作为您的首要任务。
为什么？
因为用户抱怨的时候总会到来。在我帮助过的公司中，这种情况已经发生过多次。
在这个时候才开始使用这些监控工具，就意味着您要面对客户流失的紧迫性，这并不好玩。
早点开始吧。
关于优化 WebRTC 性能的思考
关于作者 Tsahi Levent-Levi 提到的这 8 种优化 WebRTC 性能的方法，它们都很重要且实用。在整个 RTC 应用程序开发规划中，这些都是不能忽视的部分。但就像作者所说如何才能成功上线呢？您可以参考作者所说的三步 WebRTC 发布行动计划（需要付费订阅）。
幸运的是，作为实时互动领域的领先的服务商，ZEGO 对 RTC 性能的优化远远不止以上 8 点。经过 10 年的发展，ZEGO 以实时互动 RTC+AI技术为底座，建立“生于云、长于云”的云原生全球音视频云，为全球客户即刻构建了音视频云服务和行业解决方案。构建了自研的海量有序数据网络MSDN，全球设有500+节点，能帮助客户一点接入，真正实现全球实时互动。
截至目前，ZEGO 已服务全球4000多科技企业，包括70%的国内互联网头部企业，700多所学校和企事业单位，以及200多个金融及政务客户；在抗弱网、海外跨境传输以及多云商网络融合等方面达到行业领先水平，日均音视频互动时长超过30亿分钟，实时音视频覆盖全球200多个国家和地区用户。
立即联系我们👇，或立即注册即可免费体验，为您的 RTC 应用打造极致用户体验，开启业务增长之旅。
