Meta：通过 AV1 和 HD 为移动 RTC 提供更好的视频质量

过去几十年来，手机摄像头质量和流媒体视频服务的视频质量都有了极大的提高。但是，如果我们看一下实时通信（RTC）应用，虽然视频质量也随着时间的推移而提高，但始终落后于相机质量。

当我们研究如何在应用程序系列中提高 RTC 的视频质量时，AV1 成为了最佳选择。多年来，Meta 越来越多地采用 AV1 编解码器，因为它能以比特率远远低于旧编解码器的方式提供高质量视频。但是，在为移动 RTC 实施 AV1 的过程中，我们还必须应对一系列挑战，包括缩放、为低带宽用户和高端网络提高视频质量、CPU 和电池使用率以及保持质量稳定性。

提高低带宽网络的视频质量

本篇文章将重点讨论点对点（P2P，或 1:1）通话，其中涉及两个参与者。

使用我们产品和服务的用户会遇到各种不同的网络状况——有些人拥有非常好的网络，而有些人则使用受限或低带宽网络。

本图表说明了 Messenger 上某些通话的带宽分布情况：

Meta：通过 AV1 和 HD 为移动 RTC 提供更好的视频质量 — *图 1：Messenger 上 P2P 呼叫的带宽分布。*

如图 1 所示，有些通话是在非常低的带宽条件下进行的。

我们认为低于 300 Kbps 的网络都是低端网络，但我们也看到很多视频通话的带宽仅为 50 Kbps，甚至低于 25 Kbps。

请注意，这个带宽是视频编码器的共享带宽。总带宽与音频、RTP 开销、信令开销、RTX（重新传输数据包以处理丢失的数据包）/FEC（前向纠错）/重复（数据包重复）等共享。这里的主要假设是带宽估算器工作正常，并估算出真实比特率。

对于低、中、高网络没有统一的定义，但在本文中，低于 300 Kbps 的网络被视为低网络，300-800 Kbps 的网络被视为中网络，而高于 800 Kbps 的网络则被视为高网络、高清网络或高端网络。

当我们研究如何提高低带宽用户的视频质量时，主要有以下几种选择。迁移到 AV1 等较新的编解码器是最大的机会。其他选项，如更好的视频缩放器和兴趣区域编码，都提供了渐进式的改进。

视频缩放器

我们在大多数应用程序中都使用了 WebRTC，但 WebRTC 附带的视频缩放器并没有最佳的视频缩放质量。通过利用内部缩放器，我们能够显著提高视频缩放质量。

在比特率较低的情况下，我们通常会将视频缩放为 1/4 分辨率编码（假设摄像头捕捉的是 640×480 或 1280×720）。通过自定义缩放器的实现，我们看到了视频质量的显著提高。通过公开测试，我们发现峰值信噪比（PSNR）平均提高了 0.75 db。

以下是使用默认 libyuv 缩放器（盒式过滤器）的结果快照：

使用我们的视频缩放器缩小后的结果：

感兴趣区域编码

通过识别感兴趣区域（ROI），我们可以将更多的编码器比特率用在对观众来说最重要的区域（例如，头像视频中说话者的面部），从而进行优化。大多数移动设备都有应用程序接口（API）来定位脸部区域，而无需使用任何 CPU 开销。找到脸部区域后，我们就可以配置编码器，在这一重要区域花费更多比特，而在其他区域花费较少比特。要做到这一点，最简单的方法就是在编码器上设置一些应用程序接口（API），以配置相对于图像其他部分的量化参数（QP）。这些变化逐步改善了视频质量指标，如 PSNR。

采用 AV1 视频编解码器

视频编码器是影响 RTC 视频质量的关键因素。H.264 是过去十年中最流行的编解码器，硬件和大多数应用程序都支持它。但它是一种已有 20 年历史的编解码器。早在 2018 年，开放媒体联盟（AOMedia）就对 AV1 视频编解码器进行了标准化。从那时起，包括 Meta、YouTube 和 Netflix 在内的几家公司已将其大规模部署到视频流媒体中。

在 Meta，从 H.264 到 AV1 使我们在低比特率视频质量方面取得了最大的改进。

为什么选择 AV1？

我们选择使用 AV1 的部分原因是它是免版税的。编解码器许可（和并发费用）是我们决策过程中的一个重要方面。通常情况下，如果应用程序使用设备的硬件编解码器，则不会产生额外的编解码器许可费用。但如果应用程序使用的是编解码器的软件版本，则很可能需要支付许可费用。

但是，尽管大多数手机都有硬件支持的编解码器，为什么我们还需要使用软件编解码器呢？

大多数移动设备都有用于视频编码和解码的专用硬件。如今，大多数移动设备都支持 H.264，甚至 H.265。但这些编码器是为相机捕捉等常见用例设计的，而相机捕捉使用的分辨率、帧速率和比特率要高得多。目前，大多数移动设备硬件都能以极低的电池使用率实时编码 4K 60 FPS，但编码 7 FPS、320×180、200 Kbps 视频的效果往往不如在同一移动设备上运行的软件编码器。

原因在于 RTC 用例的优先级。大多数独立硬件供应商（IHV）并不了解 RTC 呼叫运行的网络条件；因此，这些硬件编解码器并未针对 RTC 场景进行优化，尤其是在低比特率、分辨率和帧速率方面。因此，我们在低比特率情况下使用软件编码器来提供高质量视频。

由于我们不能在没有许可证的情况下提供软件编解码器，因此 AV1 是 RTC 的一个非常好的选择。

用于 RTC 的 AV1

采用更先进的视频编解码器的最大原因很简单：我们可以用低得多的比特率提供相同质量的体验，从而为使用带宽受限网络的用户提供质量高得多的实时通话体验。

衡量视频质量是一个复杂的话题，但相对简单的方法是使用 Bjontegaard Delta-Bit Rate（BD-BR）指标。BD-BR 比较各种编解码器需要多少比特率才能产生一定的质量水平。通过以不同比特率生成多个样本，测量生成视频的质量，可以得到速率-失真（RD）曲线，根据 RD 曲线可以得出 BD-BR（如下图所示）。

从图 4 中可以看出，在我们的本地测试中，AV1 在所有比特率范围内都能提供更高的质量。

屏幕编码工具

AV1 还有一些对 RTC 非常有用的关键工具。屏幕内容的质量正成为 Meta 越来越重要的因素，包括屏幕共享、游戏流媒体和 VR 远程桌面在内的相关使用案例都需要高质量的编码。在这些领域，AV1 确实大放异彩。

传统的视频编码器并不适合复杂的内容，如含有大量高频内容的文本，而人类对阅读模糊的文本非常敏感。AV1 拥有一套编码工具——调色板模式和块内复制，可大幅提高屏幕内容的性能。调色板模式是根据屏幕内容帧中的像素值通常集中在数量有限的颜色值这一观察结果而设计的。调色板模式可以通过颜色集群信号而不是量化的变换域系数来有效地表示屏幕内容。此外，对于典型的屏幕内容，在同一画面中通常会出现重复的模式。块内复制有助于在同一帧内进行块预测，从而显著提高压缩效率。AV1 在基线配置文件中提供了这两种工具，这是一大优势。

参考图像重采样减少关键帧

另一个有用的功能是参考图片重采样（RPR），它允许在不产生关键帧的情况下改变分辨率。在视频压缩中，关键帧是独立编码的帧，就像静止图像一样。它是唯一一种可以在没有其他帧作为参考的情况下进行解码的帧。

对于 RTC 应用来说，由于带宽经常变化，因此需要经常改变分辨率以适应这些网络变化。使用 H.264 等老式编解码器时，每次分辨率变化都需要一个大得多的关键帧，因此对于 RTC 应用程序来说效率很低。这样大的关键帧会增加需要通过网络发送的数据量，导致更高的端到端延迟和拥塞。

通过使用 RPR，我们可以避免生成任何关键帧。

提高低带宽用户视频质量面临的挑战

CPU/ 电池使用量

AV1 可提高编码效率，但编解码器实现这一目标的代价是较高的 CPU 和电池使用率。在移动平台上运行实时应用程序时，许多现代编解码器都会带来这些挑战。

根据本地实验室测试，我们预计电池使用量会增加约 4%，在公开测试中我们也看到了类似的结果。我们使用电量计进行了本地电池测量。

尽管 AV1 编码器本身的 CPU 占用率比 H.264 执行时增加了三倍，但编码器对 CPU 占用率的总体贡献仅占电池使用量的一小部分。手机显示屏、网络/无线电和其他使用 CPU 的进程对电池使用量的贡献很大，因此电池使用量增加了 5-6%（电池使用量显著增加）。

很多通话都会耗尽设备电池，或者一旦操作系统显示电池电量不足，用户就会挂断电话，因此，除非能提高视频质量等附加价值，否则提高电池使用率对用户来说并不值得。即便如此，也要在视频质量和电池使用之间做出权衡。

我们使用 WebRTC 和会话描述协议 (SDP) 进行编解码器协商，这使我们能够预先协商多种编解码器（如 AV1 和 H.264），然后切换编解码器，而无需在通话过程中发出信号或握手。这意味着编解码器的切换是无缝的，用户不会注意到视频中的任何闪烁或停顿。

我们创建了一个自定义编码器，同时封装 H.264 和 AV1 编码器。我们称之为混合编码器。这样，我们就可以在通话过程中根据 CPU 使用率、电池电量或编码时间等触发因素切换编解码器，并在需要时切换到更省电的 H.264 编码器。

崩溃和内存不足错误增加

即使不增加新的泄漏，AV1 也比 H.264 占用更多内存。任何时候，只要使用了额外的内存，应用程序就更有可能发生内存不足（OOM）崩溃，或者因为其他泄漏或其他应用程序对系统内存的需求而更快发生 OOM。为了缓解这一问题，我们不得不在内存不足的设备上禁用 AV1。这是需要改进和进一步优化编码器内存使用的一个方面。

产品内部质量测量

为了通过公开测试比较 H.264 和 AV1 的质量，我们需要一个低复杂度的指标。编码比特率和帧速率等指标不会显示任何改进，因为发送视频的总带宽仍然相同，因为这些指标受到网络容量的限制，这意味着视频的比特率和帧速率不会随着编解码器的改变而有太大变化。我们一直在使用综合指标，将量化参数（QP 通常被用作视频质量的代表，因为这会在编码过程中造成像素数据丢失）、分辨率和帧频结合起来，并将其冻结以生成视频综合指标，但 AV1 和 H.264 编解码器之间的 QP 不具可比性，因此无法使用。

PSNR 是一种标准指标，但它基于参考，因此不适用于 RTC。非参考的视频质量度量相当耗费 CPU（如 BRISQUE：盲/无参考图像空间质量评估器），不过我们也在探索这些方法。

我们提出了一个 PSNR 计算框架。我们首先修改了编码器，以报告压缩造成的失真（大多数软件编码器已经支持这一指标）。然后，我们设计了一种轻量级缩放失真算法，用于估算视频缩放带来的失真。该算法可将这些缩放失真与编码器失真结合起来，以产生输出 PSNR。我们在本地开发并验证了这一算法，并将在明年的出版物和学术会议上分享研究成果。通过这种轻量级 PSNR 指标，我们发现 AV1 比 H.264 提高了 2 分贝。

提高高带宽网络视频质量面临的挑战

简单回顾一下：就我们而言，高带宽包括带宽超过 800 kbps 的用户。

多年来，摄像机的拍摄质量有了很大提高。因此，人们的期望值也随之提高，他们希望看到 RTC 视频质量与本地摄像头捕捉质量相当。

根据本地测试，我们最终确定了视频质量与摄像头拍摄质量相似的设置。我们称之为高清模式。我们发现，在使用 H.264 等视频编解码器以 3.5 Mbps 和每秒 30 帧的速度编码时，720p 分辨率看起来与本地摄像头拍摄的视频非常相似。我们还在主观质量测试中比较了 720p 和 1080p，发现在大多数设备上，除了那些屏幕较大的设备外，我们进行主观质量测试时，两者的差异并不明显。

带宽估算器改进

对于那些拥有配备良好 CPU、电池、硬件编解码器和良好网速的高端手机的用户来说，提高视频质量似乎微不足道。似乎只要提高最大比特率、捕获分辨率和捕获帧速率，用户就能发送高质量视频。但实际上，事情并非如此简单。

如果提高比特率，您的带宽估算和拥塞检测算法就会更频繁地遇到拥塞，您的算法将比不使用这些较高比特率的情况下接受更多次测试。

如果查看图 7 中的网络管道，使用的比特率越高，算法/代码在 RTC 呼叫期间接受的鲁棒性测试就越多。图 7 显示了使用 1 Mbps 比 500 Kbps 时的拥塞程度，以及使用 3 Mbps 比 1 Mbps 时的拥塞程度，依此类推。但是，如果您使用的带宽低于网络的最小吞吐量，则根本不会出现拥塞。例如，请参见图 7 中 500-Kbps 的呼叫。

为了缓解这些问题，我们改进了拥塞检测。例如，我们添加了自定义 ISP 节流检测，而传统的基于延迟的 WebRTC 估算器无法检测到这种情况。

带宽估算器和网络弹性本身就是一个复杂的领域，而这正是 RTC 产品脱颖而出的原因。他们拥有自己的定制算法，最适合自己的产品和客户。

人们不喜欢视频质量的波动。当我们在几秒钟内发送高质量视频，然后又因为拥堵而降回低质量时，就会出现这种情况。吸取过去的教训，我们在带宽估算中增加了支持，以防止这种振荡。

对于 RTC 而言，音频比视频更重要

当网络拥塞时，所有媒体数据包都可能丢失。这会导致视频冻结和音频中断（又称机器人音频）。对于 RTC 来说，这两种情况都很糟糕，但音频质量比视频更重要。

损坏的音频往往会完全阻止对话的进行，经常导致人们挂断电话或重新拨号。另一方面，损坏的视频通常会导致对话不那么愉快，但根据不同的场景，它也可能成为某些用户的障碍。

在高比特率（如 2.5 Mbps 或更高）条件下，音频数据包的数量可以增加三倍到五倍，视频也不会出现明显的质量下降。当使用手机连接以这些更高的比特率运行时，我们看到了更多的拥塞、丢包和 ISP 节流问题，因此我们不得不对网络弹性算法进行修改。由于人们对手机上的数据使用非常敏感，我们禁用了手机连接上的高比特率。

何时启用高清？

我们使用基于 ML 的目标定位来猜测哪些通话应支持高清。我们依靠用户之前通话的网络统计数据来预测是否应该启用高清功能。

电池损耗

我们有很多指标（包括性能、网络和媒体质量）来跟踪 RTC 通话的质量。当进行高清测试时，我们发现电池指标出现了倒退。我们发现，大多数电池性能下降不是因为比特率或分辨率提高，而是因为捕获帧速率提高。

为了减少电池损耗，我们建立了一种机制来检测呼叫方和被呼叫方的设备能力，包括设备型号、电池电量、Wi-Fi 或移动设备使用情况等。为了启用高质量模式，我们会检查通话双方，确保他们满足要求，然后才会启用这些高质量、资源密集型配置。

RTC 的未来是什么

硬件制造商正在认识到将 AV1 用于 RTC 的显著优势。新款苹果 iPhone 15 Pro 支持 AV1 硬件解码器，谷歌 Pixel 8 支持 AV1 编码和解码。硬件编解码器是高端网络和高清分辨率的绝对必需品。视频通话正变得像传统音频通话一样无处不在，我们希望随着硬件制造商认识到这一转变，RTC 应用程序创建者和硬件制造商之间将有更多的合作机会，为这些应用场景优化编码器。

在软件方面，我们将继续努力优化 AV1 软件编码器，并开发新的编码器实施方案。我们努力为用户提供最佳体验，但同时我们也希望让用户能够完全控制自己的 RTC 体验。我们将为用户提供控制功能，让他们可以选择是否需要以电池和数据使用量为代价来获得更高的质量，反之亦然。

我们还计划与 IHV 合作开发硬件编解码器，使这些编解码器适用于 RTC 场景，包括低带宽使用案例。

我们还将研究视频处理等前瞻性功能，以提高接收器渲染堆栈的分辨率和帧速率，并利用人工智能/ML 改进带宽估算 (BWE) 和网络弹性。

此外，我们还在研究 Pixel Codec Avatar 技术，该技术将允许我们一次性传输模型/共享，然后发送几何体/向量供接收端渲染。与传统的视频编解码器相比，这种技术能在 RTC 场景中以更小的带宽使用率进行视频渲染。