WebRTC 视频质量调校

原文链接：https://bloggeek.me/tweaking-webrtc-video-quality-unpacking-bitrate-resolution-and-frame-rates/ 原标题：Tweaking WebRTC video quality: unpacking bitrate, resolution and frame rates 翻译整理：李昊勇 这篇文章主要介绍了 WebRTC 中的一些限制，并深入介绍了比特率，分辨率和帧率对服务质量的影响，以及如何对这三者进行抉择。

目录

• 开头
• 什么在 WebRTC 中影响着视频质量
  • 超出可控范围的
  • 服务相关
  • 设备相关
• WebRTC 视频质量的三脚凳
• 追随比特率
• 在分辨率和帧率之间做出选择
• 是时候学习 WebRTC 了

1开头

WebRTC 视频质量需要一些调校来正确完成。让我们看看我们在比特率、分辨率和帧率方面有哪些可用的级别。

实时视频传输有难度。WebRTC 可能会让这件事变得更容易一些，但仍然有一部分需要处理。特别是如果你想要为你的应用榨干 WebRTC 的视频质量来改善用户体验的时候。

这次，我想介绍一下我们可以使用的影响视频质量的杠杆，以及如何正确使用它们。

2什么在 WebRTC 中影响着视频质量

如今，视频在交流中发挥着重要作用，视频通话/会话/会议将在很大程度上依赖于视频质量。

但是什么影响了视频质量呢？让我们尝试将它们分为 3 个主要部分：我们无法控制的、服务相关的和设备相关的。我们就能够专注于我们可以控制的事情以及我们应该努力的地方。

超出可控范围的

图 1.可控、可影响、以及不可控且不可影响

有些事情是我们无法控制的。我们有能力影响他们，但也只是在一定程度上。在极端情况下，如果用户坐在南极洲的电梯里，在地下室某处，没有互联网连接，也没有手机信号接收。即使他抱怨电话没有接通，除了建议他让自己靠近 Wifi 接入点之外，任何人都无能为力。

我们无法真正控制的主要的两件事是什么？使用的带宽和传输协议。另外，我们也无法控制用户的设备及其功能，但大多数时候，人们往往会理解这一点。

带宽

带宽是我们可以通过网络发送或接收的数据量。该值越高越好。问题是，我们几乎无法控制它：用户可能离他的接入点很远、他可能接收不好、有故障的电缆、可能还有其他人使用相同的接入点并用他们自己的数据淹没它、有人可以配置防火墙来限制流量等等。这一切都不在我们的控制范围内。虽然我们可以做一些小事来改善这一点，例如将我们的服务器放置在尽可能靠近用户的地方，但除此之外别无他法。

我们对带宽的作用是尽可能准确地估计它。WebRTC 具有带宽估计机制。如果我们知道有多少带宽可供我们使用，我们就可以尝试更好地利用它。高估带宽意味着我们最终可能会发送超出网络处理能力的数据，这反过来会导致拥塞，降低服务质量；低估带宽意味着我们发送的数据将少于我们所能拥有的数据，这最终也会降低我们可以提供给用户的媒体质量。

传输协议

将 TCP 用于 WebRTC 并不是一个好主意。问题是，你并不能真正控制选择什么。在大多数情况下，这就是会话分布的样子：

图 2.TURN 服务器使用的协议分布

大多数呼叫可能不需要任何 TURN 中继，大多数需要 TURN 中继的呼叫将通过 UDP 进行，其余的可能会通过 TCP 完成，并且会有那些必须有 TLS 的会话。这是因为网络的配置不同。而你无法控制它。一旦你达到与上述类似的分布，或者一旦你知道如何解释在会话分布方面所看到的内容，那么你就没有其他需要优化的地方了。

服务相关

服务相关的是我们控制范围内的事情，通常在我们的基础设施中处理。这就是基于架构和部署后端的差异将发挥作用的地方。

比特率

虽然带宽不是我们可以控制的，但比特率是。带宽是网络可以发送或接收的上限，比特率是我们通过网络实际发送和接收的内容。

图 3.比特率和带宽

我们不能发送超过带宽允许的内容，而且我们可能也不总是希望发送我们可以发送的最大比特率。我们需要最适合我们需求的比特率，意味着我们需要：尽可能准确地估计可用带宽；估计带宽是我们可以使用的最大比特率；只要这能给我们带来质量的提升，就尽可能多地利用该比特率。

重要的是，提高比特率并不总是提高质量。它也可能导致质量的不利下降。这里有一些例子：

• 如果我们拥有的摄像机源是 VGA 分辨率（640×480），则不需要通过网络发送 2mbps。800kbps 就足够了。即使发送的比特率高于此值可能也看不到任何质量差异。
• 网络可能能够在下行链路中传输 10mbps，但是从 5 个参与者（每个 2mbps）接收总共 10mbps 的传入视频数据可能会使我们的 CPU 负担过重以至于无法有效工作，从而导致丢帧和媒体质量不佳。
• 因为并行共享的内容更重要，因此发送全高清视频（1920×1080）并在屏幕上以小框显示，这是一种浪费。我们正在消耗宝贵的网络资源、解码器 CPU 并缩小图像。

编解码

图 4.编解码器

编解码器会影响媒体质量。对于音频，G.711 很差，Opus 很棒。Lyra 和 Satin 作为下一代看起来很有希望。视频方面，你可以选择 VP8、VP9、H.264、HEVC 和 AV1。

在为你的 WebRTC 应用程序选择视频编解码器时，需要考虑以下几点：

• VP8 和 H.264 都运行良好，广为人知和使用。
• 在相同比特率下，VP9 和 HEVC 提供比 VP8 和 H.264 更好的质量。
• AV1 的性能优于所有其他视频编解码器。但它是新的，并没有得到广泛的支持或理解。
• H.264 有更多可用的硬件加速，但 VP8 具有时间可扩展性，这很有用。
• 硬件加速有时被高估了。它甚至可能十分难以使用，但如果有真正的需要，它是值得瞄准的。
• 对于小组会议，如果你希望使用simulcast 或 SVC，然而这些可能不适用于 HEVC。
• HEVC 将让你进入只有 Apple 的世界。
• VP9 没有被广泛使用，它所拥有的 SVC 的实现仍然是相当专有的，所以你在这里需要做一些逆向工程。
• AV1 非常新，而且它会吃很多CPU，它有它独特的地方。

为你的服务选择视频编解码器并不是一项简单的任务。如果你不知道自己在做什么，请坚持使用 VP8 或 H.264。对编解码器进行实验是一种浪费时间的方式，除非你了解它们的使用方式。

延迟

图 5.延迟

你如何设计 WebRTC 基础架构将影响延迟。虽然我们无法控制用户的位置，但我们绝对可以控制我们的服务器所在的位置。这意味着我们可以将服务器放置在离用户更近的地方，从而降低延迟。

这里有一些事情需要考虑：

• TURN 服务器应尽可能靠近用户放置；
• 在大型群组通话中，我们必须有媒体服务器；
• 如果我们每次会议使用一台服务器，那么所有用户都必须直接连接到它；
• 但是如果我们分发用于单个会议的媒体服务器，那么我们可以将用户连接到更靠近他们所在位置的媒体服务器；
• 我们越快从公共网络上获取用户的数据，我们就越能控制我们自己的服务器之间的数据包路由；
• 从用户到我们服务器的路径越“短”，质量就越好。较短的可能不是地理距离，而是带宽、数据包丢失、抖动和延迟作为衡量指标来决定“最短”。

设备相关

可用的 CPU

这应该是你的首要任务：了解用户设备上使用了多少 CPU ，并确认什么程度会超出可承受范围。

当设备“CPU 不足”时会发生什么？

• CPU 会发热。这是最重要的问题：风扇将开始在 PC 上忙碌而嘈杂地工作。移动设备会发热。它的电池寿命也会开始缩短。
• WebRTC 将无法编码或解码媒体帧，因此它将开始跳过这些帧。
• 在编码器方面，这将意味着较低的帧率。
• 解码器是事情开始变得混乱的地方：
• 解码器将丢帧而不尝试解码它们。由于视频帧相互依赖，这将意味着解码器将无法继续执行它所做的工作，它将需要一个新的 I-frame 并会要求它。这将导致视频冻结，使视频崩溃。

最终就会导致：

• 你最终的视频质量很差并且视频崩溃；
• 由于频繁请求 I 帧，网络变得更加拥挤；
• 你的设备发热并且电池寿命受到影响。

你需要监控并确保 CPU 使用率不会太高，降低 CPU 使用率的最佳工具是降低发送和/或接收的比特率。遗憾的是，在浏览器本身中直接监控 CPU 是不可能的，你需要找到其他方法来确定 CPU 的状态。

内容类型

对于视频，其内容和展示位置很重要。假设你有 1,000kbps 的“预算”。这是因为带宽估算器为你提供了该数量，并且你知道/假设发送方和接收方的 CPU 都可以处理该比特率。你如何花这笔预算？

• 你需要弄清楚要发送的分辨率。分辨率越高，图像看起来“越好”。
• 提高帧率？更高的帧率会给你更流畅的动作。
• 或者也许只是在你发送的任何内容上投入更多比特率。

WebRTC 会自己做决定。这些基于可用的比特率。它会自动决定增加或减少分辨率和帧率，以适应它认为最好的质量。你甚至可以传递有关你的内容类型的提示——你是否重视流畅度而不是清晰度，反之亦然。

WebRTC 仍然有自己无法知道一些信息：

• 它知道你用什么分辨率捕获内容（因此它不会尝试以比该分辨率更高的分辨率发送它），但它不知道观众的屏幕或窗口分辨率是多少。因此它可能会发送超出需要的数量，从而导致会话两端的 CPU 和网络损失。
• 它不知道发送的内容是重要还是不重要，这会影响开始时对比特率投资多少的决定。
• 它在设备上做出决定。如果你有一个处理媒体的媒体服务器，那么所有的好处都需要在你的媒体服务器和它自己的逻辑中发生。

弄清楚这些事情并从视频中选择/移除你想要的内容的某些限制将是你的工作。

优化大型组呼

会议规模越大，你的代码就越具有挑战性，且需要更多优化以支持它。WebRTC 为你提供了许多强大的工具来扩展会议，但它还有很多需要你去弄清楚。

3WebRTC 视频质量的三脚凳

图 6 WebRTC 三角凳

WebRTC 中的视频质量就像一个三脚凳。在所有条件相同的情况下，你可以调整比特率、帧率和分辨率。至少，当你处于会话中间并需要做出决定时，这就是你可以实时动态处理的内容。

比特率可以被视为凳子中最重要的部分，另外两的帧率和分辨率非常依赖于彼此。如果我们希望保持图像质量，一个改变将立即迫使另一个改变。增加或减少比特率会导致帧率和分辨率发生变化。

另外两个，帧率和分辨率非常依赖于彼此。如果我们希望保持图像质量，一个改变将立即迫使另一个改变。增加或减少比特率会导致帧率和分辨率发生变化。

4追随比特率

有很多开发人员开始调整帧率或分辨率。虽然这是令人钦佩的，有时甚至是合理的，但这是错误的起点。

你应该做的是追随 WebRTC 中的比特率。首先弄清楚并真正了解你的预算中有多少比特率。然后根据你的限制决定如何分配比特率：

• 不要指望全高清质量，例如，如果你的比特率预算为 300kbps - 这是不可行的；
• 如果你有 800kbps，则需要决定将它们投入到何处——分辨率还是帧率。

总是从比特率开始，然后根据 CPU、设备、屏幕分辨率、内容类型……以及通常的会话上下文，找出你对分辨率和帧率的限制。在大多数情况下，最好在你拥有的内容类型上“提示”WebRTC，并让 WebRTC 弄清楚它应该做什么。

5在分辨率和帧率之间做出选择

一旦我们确定了比特率，接下来你应该追求更高的分辨率还是更高的帧率？

这里有一些指导方针供你使用：

• 如果你的内容是幻灯片或类似的静态内容，你应该以较低的帧率获得更高的分辨率。如果可能，请使用 VBR 而不是 WebRTC 中的默认 CBR；
• 假设你在谈话领域，更高的帧率是更好的选择。30fps 是我们的目标，但如果比特率很低，你也需要降低它。看到服务以 15fps 运行并且仍然对结果感到满意是很常见的；
• 如果是共享来自 YouTube 或类似内容的通用视频内容，帧率比分辨率更重要；
• 在屏幕上显示 9 个或更多参与者？请将帧率降低到 15fps（或更低）。还要确保你接收的视频的分辨率没有高于你显示的分辨率；
• 对共享内容的清晰度感兴趣？以分辨率为目标，牺牲帧率。

6是时候学习 WebRTC 了

我们最近与使用 WebRTC 但对 WebRTC 不够了解的供应商进行了相当多的讨论，通常结果并不令人满意，无法达到如今被认为是良好的媒体质量，都是因为错误的假设或适得其反的糟糕优化。

如果你打算使用或正在使用 WebRTC，那么你应该更好地了解它，了解它的工作原理并确保你正确使用它。