Meta 用于实时通信的 AV1 视频编解码器

AV1 正在成为流媒体世界的主流，现在也是利用它进行实时通信的时候了。Niklas 将分享 Meta 从 AV1 集成中获得的经验，讨论可以采取的权衡和缓解措施，以减少负面影响，并涵盖可以获得的最大收益。

演讲者：NIKLAS ENBOM

视频地址：https://atscaleconference.com/videos/av1-for-meta-rtc/
内容整理：杨晓璇

引言

Niklas 是 Meta 的工程师，目前在为 Meta 家族的视频通话部门工作。Niklas 将介绍目前采用 AV1 视频编解码器进行实时通信（RTC）的案例，本次介绍将从系统集成的视角出发，专注于大规模的编解码器生成转变。

AV1 简介

为什么使用 AV1？Meta 希望为用户提供更高质量的、更有沉浸感的视频通话。在讲解具体的技术之前，先来看下面的对比。图片上的人是 Eric，Niklas 的同事，在同等的网络条件下（300kb/s）,左边是使用 H264 视频编码器的视频通话效果，右边则是使用 AV1 的效果，使用肉眼可以很明显地看出区别，右边明显更清晰。这就是 Meta 想要给用户的质量提升。

现在回到 AV1，AV1是开放媒体联盟 Alliance for Open Media (AOM) 开发的第一代视频编码标准，于 2018 年推出。在这之后，AV1 的执行版本不断被改进，在近两年已经被流媒体公司广泛采用，包括 YouTube、Netflix，Meta 也是 AOM 的一员。

相比于 Meta 的流媒体业务，实时视频通信是一个滞后的选项。因为这需要在硬件上实现编码和解码的的实时。但现在是时候使用 AV1 了。现在已经有很多经济的、开源的方案来实现实时通信。因特尔、高通等公司也提供了硬件支持。libAOM 的活跃使得实时编码方案不断优化，这对实时编码的发展是很重要的。

AV1 的优势

Niklas 在编码行业已经有相当一段时间了，从最开始的音频到现在做视频编码，他见证了很多标准的迭代与发展。这一次，AV1 实现了巨大的进步。HEVC 或 x265 从未被大规模广泛使用过或应用于实时通信，因为它的专利实在太混乱。这意味着要从 20 年前的行业标准开始研究。AV1 的出现和广泛应用，既是机会也是挑战。

现在来看 AV1 的定量分析。使用 BD-rate 衡量媒体的质量是一个直接有效的办法，它表示生成指定质量的图像所需要的比特速率，通过生成不同的视频可以计算速率-质量曲线。在上图中可以看到，使用 AV1 有 30-40% 的性能提升。这些性能提升大部分时候不会被用来节省带宽，而是被用来向用户提供更高质量的视频。AV1 性能的提升对视频通体验的影响是显著的。

屏幕内容正在成为越来越重要的案例，比如游戏实时，远程桌面操控等。这些情况需要在低延迟下实现高质量的编码，AV1 发挥了巨大作用。通常视频编码器在屏幕内容上表现不佳，特别是文本或含有大量高频信息的视频。AV1 中的高级编码工具可以在视频内容图像上实现 80% 的性能增益，这是一个巨大的进步。可以从下图中看到 AV1 在屏幕内容上的优势。在高分辨率上，这样的优势也是明显的。

分辨率改变在实时通信中是很常见的情况，因为比特率范围变化很大。Reference Picture Resampling(RPR) 技术使得在实时视频通话过程中分辨率改变时，不需要重新生成关键帧，这是一个很大的进步。当网络质量下降，视频分辨率也被迫下降时，最差的情况是生成代价昂贵的关键帧。通过统计发现，发送的关键帧数目与视频质量有直接关系，目前 AV1 平均每分钟生成 1.5 张关键帧来应对分辨率改变的挑战。

目前，像其他许多人一样，Meta 正在使用同步广播进行大型呼叫，当涉及到向每个个体用户提供高质量视频时，这肯定是有限制的。同步广播也是产生过多关键帧的一个主要来源。如果在真正的大型呼叫中进行过滤，实际上每分钟要生成多达 4 个关键帧的变化生成，只是为了支持同步广播层的切换。

AV1 实时通信的挑战

Niklas 提到AV1已经被用于流媒体，与实时通信相比，这种情况总是早几年发生。首先，流媒体不必在设备上做实时编码，同时也能负担得起在后端做非常昂贵的编码，因为实际上可以反复使用这些内容。Meta 也有能力做两遍编码，使速率控制和质量控制更加精确。对于流媒体服务，比特率和你的发行成本之间也有直接的联系，这使得更容易决定是否应该投资于更先进的编解码器。对于实时通信，就完全不同了。Niklas 说：“为了决定我们是否应该投资 AV1 的实时通信，我们从一个离线评估项目开始。我们在质量和性能方面对两种不同的实现方式进行比较，同时也将其与我们现有的解决方案进行比较。我们将其映射到我们的用户数据中，以估计我们将能够达到哪个百分比，同时也估计他们会得到多大的质量收益。之后，我们开始进行第一组整合。为了能够实时展示这一点，我们把问题变得简单一些，例如，在我们的桌面客户端上运行AV1，为员工使用，以便能够把我后面要讲的一些已知问题放在一边。但无论如何，我们能够确保我们能够发现是否有任何我们必须解决的未知问题，我们也能够验证我们的评估结果。我们现在正在努力的最后一步是真正将其扩展到我们的整个用户群。如你所知，我们是一个专注于消费者的平台，我们在整个地球上有一个非常多样化的用户群。这意味着我们必须更保守一些。”

以 Binary Size 为例，如果将 libAOM 整合到 WebRTC 中，将会给应用程序增加大约 1M 字节，或者给分发大小增加 500K。如果是一家初创公司，试图获得第一个用户，这是需要关心的一个问题。但 Meta 是一家为数十亿人服务的公司，这就是一个需要克服的主要障碍。二进制规模会影响成功率，如果升级成功率较低，这意味着会有更多的用户卡在所有的客户端。二进制大小也影响到应用程序的启动时间和进入来电的时间。呼叫的铃声是一个超级关键的开始。二进制大小也会影响一般的软件健康指标，如内存使用。将二进制大小增加 500k 是一件大事。这可能相当于一个大型团队全年的功能预算。不可能就这样去增加它，然后测量它的收益。首先需要从我们的用户那里获得真正可靠的数据。正因为如此，最初是依靠一个动态的下载框架，将 AV1 作为一个独立的组件下载，并为有带宽的客户提供特色服务。长期来看，需要投资减少库的大小调用，Niklas 希望能与 libAOM 合作，这将使 Meta 在旧的客户端默认包括 AV1。Niklas 也在考虑通过重复使用我们已经有的解码器来节省其他一些二进制大小的影响。例如，一个应用程序可能已经有一个用于视频流的 AV1 解码器，在某些情况下，操作系统也包括一个解码器。

对于某些用户来说，二进制大小可能不是一个问题。然而，CPU的使用将是一个问题。视频压缩总是在质量、比特率和处理要求之间进行权衡。因此，即使在本地复杂模式下使用 AV1，与 H264 解决方案相比，它仍然是昂贵编码。通话时间是第一顶级指标。Meta 不会推出任何减少通话时间的功能。需要知道，电池的使用和通话时间之间有直接的联系。如果你增加 1% 的电池使用量，你的平均通话时间将下降几乎相同的数量。幸运的是，提高质量将推动通话时间的增加，但需要确保取得正确的平衡。

Niklas 说：“首先，我们必须先确定转向 AV1 的实际电力成本是多少。幸运的是，增加三倍的编码负荷并不意味着你的电力消耗增加三倍。例如，我们知道，通常手机上最大的电力消耗是显示屏。即使 SOC 排在第二位，那也是用于应用程序和编码中的许多其他应用程序和功能。为了确定真正的成本，我们测量了使用 AV1 和 H264 进行正常通话时的实际电力利用率。我们连接通话，绕过电池，并在通话时直接连接到功率计。与 H264相比，切换到 AV1 时，功率增加了 110 毫瓦。在一个典型的通话场景中，这是一个 4% 的增长，这取决于其他因素，如屏幕亮度和背景活动。因此，这是我们必须要处理和克服的数字。尽管 4% 比 300% 小得多，但它还不足以让我们盲目地为所有客户提供 AV1。我们需要确保我们的利益最大化，同时我们也尽量减少任何负面影响。”

一种方法是利用动态编码切换，在 AV1 和其他低复杂度的编码方案中动态切换。即使正常的使用情况 Meta 坚持使用最高优先级的编解码器。低比特率的呼叫将从 AV1 中受益最多。比较好的是，低比特率的呼叫通常使用较低的分辨率和较低的帧率，这使得编码成本在总功率中的比例较小。因此，通过根据比特率分辨率动态切换编解码器，这使得能够找到一个平衡点，获得质量上的提高，而不会引入退步。更聪明的方法是把其他因素考虑进去。例如，你可以看一下设备信息。这是一个高性能的 CPU 吗？这个设备有大电池吗？或者可以更聪明一些，看看代码期间的实际电池情况。切换到 AV1 是否使我们在这个手机上遇到电池不足的情况。

还有一组较小的挑战需要解决。首先，速率控制对于实际时间来说是非常重要的。速率控制的好坏与视频冻结之间有直接的联系。在另一方面 AV1 与 H264 解决方案不相上下。这并不奇怪，因为已经为 H264 做了大量改进工作。但是现在已经能够努力调整 AV1 实现，实际上已经与 H264 持平。而 Niklas 现在刚刚开始与谷歌讨论如何将这一功能上升到 libAOM ，并使其对所有用户可用。

总结

目前，AV1 已被大规模使用。但是对于移动部署来说，这将是一个漫长的旅程，将至少花一整年的时间来增加移动部署。同时，Meta 也在努力将 AV1 用于其他用例，例如 VR。多种编解码器将长期共存，甚至可能是永远共存。H264不会很快消失。而且，新技术可能马上出现，VVC 和 AV2 已经在路上了。因此，Niklas 认为必须准备好自己的架构，以面对这种长期的多编码共存。

Niklas 希望介绍能有所帮助，如果有问题可以通过邮箱 niklase@meta.com 联系他。