Meta：在实时通信（RTC）领域大规模采用 AV1

作者：Yu-Chen (Eric) Sun, Jie Dong, Kewei Huang, Dave Jack, Joachim Reiersen, Phil Scherbel, Karthik Sekuru, Vertika Singh, Thileepan Subramaniam, Wei Zhou
原文：https://engineering.fb.com/2026/06/22/video-engineering/adopting-av1-for-real-time-communication-rtc-meta/

AV1 视频编解码器由 AOMedia 于 2018 年首次标准化，此后发展迅速，并获得了广泛的行业支持。如今，YouTube、Netflix 和 Meta 等领先公司已大规模使用 AV1 进行视频流传输。Meta 于 2023 年在高端设备上推出了支持 AV1 的实时视频通话功能，旨在提供卓越的通话质量。此后，我们在扩大 AV1 的应用范围和提升 AV1 通话体验方面取得了显著进展。目前，Meta 的 Messenger 和 WhatsApp 等实时通信 (RTC) 应用已在大多数移动设备上启用 AV1。

Meta为何对在RTC中采用AV1感兴趣？ 

切换到更先进的视频编解码器的动机很简单。它能在保证相同视觉质量的同时，大幅降低带宽占用。在离线测试中，我们观察到，在低端和中端设备上，使用 AV1 编解码器时，相比 H.264/AVC，在我们的产品设置下，比特率至少降低了 20%。如果设备能够支持更高的编码复杂度，比特率的降低幅度会更大。对于实时视频通话而言，这意味着网络速度较慢或带宽有限的用户可以享受到显著提升的视频质量。这对我们的用户至关重要，因为为了满足低延迟要求，RTC 产品必须能够应对比特率波动。在实际网络中（尤其是在新兴市场）RTC 产品的视频比特率通常在 10 kbps 到 400 kbps 之间。在低于 100 kbps 的比特率下保持良好的视频质量仍然是一个挑战。

为了评估不同视频编解码器的用户体验，我们在 Messenger 应用中启用了 AV1，并使用两部安卓手机进行了并排对比。在示例中，H.264/AVC 视频明显模糊，而 AV1 视频则清晰得多——这凸显了 AV1 在带宽受限的情况下进行视频通话的显著优势。

屏幕内容日益受到重视，这需要高质量的计算机生成内容编码来支持。传统的视频编码器不太适合处理复杂的文本内容，例如包含大量高频元素的文本，而人们对模糊的文本非常敏感。AV1 提供了一系列编码工具，比如调色板模式和块内复制，这可以显著提升屏幕内容的性能。

调色板模式的设计基于这样的观察：屏幕内容帧中的像素值通常集中在有限数量的颜色值上。它通过指示颜色簇而非量化的变换域系数来高效地表示屏幕内容。此外，对于典型的屏幕内容，同一画面中通常存在重复的图案。块内复制有助于在同一帧内进行块预测，从而显著提高压缩效率。AV1 的优势在于其主配置文件中提供了这两种工具。

采用 AV1 面临的挑战

虽然对比结果清晰地展现了AV1的优势，但它在实时通信（RTC）领域的应用仍面临诸多挑战。与视频点播（VOD）不同，RTC系统必须管理端到端的视频延迟，理想情况下，延迟应低于300毫秒。如果延迟超过此阈值，人们就会开始注意到对话的延迟。

同时保持高视频质量和低延迟是一项挑战。例如，多遍编码技术虽然可以提高视频质量，但会引入额外的延迟。在解码器端，大量的缓冲也会进一步增加延迟。此外，比特率的任何突然飙升都可能导致通话期间视频卡顿，从而降低用户体验。

RTC 产品还必须能够在通话过程中动态适应网络状况。网络带宽波动和丢包是两大挑战。为了应对带宽变化，视频编码器会调整分辨率和帧速率等参数。然而，切换分辨率通常需要生成新的关键帧，这可能导致比特率突然飙升和视频短暂卡顿。同样，丢包会触发重传或迫使编码器发送另一个关键帧，这两种情况都可能导致视频卡顿。有效管理这些问题有助于实现高质量、不间断的视频通话。

此外，RTC 客户端必须执行实时编码和解码，这两项操作都会消耗大量电力。因此，能效非常重要，尤其是在移动设备上。

编码器和解码器选择

选择合适的编码器和解码器是采用新编解码器时最关键的一步。视频编解码器的计算复杂度对于移动设备而言是一个重要的考量因素。虽然 AV1 通过先进的编码工具提高了压缩效率，但这些优势也带来了更高的计算需求，尤其是在编码过程中。

为了评估这种复杂性的增加，我们在离线实验中集成了一个开源的AV1编码器，并测量了Pixel 8设备在视频通话期间的功耗。结果显示，与H.264/AVC相比，功耗增​​加了14%——这对移动部署来说是一个巨大的挑战。为了解决这个问题，我们采用了一个内部的低复杂度编码器，其功耗与H.264基准编码器相近，详情将在下一节中介绍。

除了功耗之外，与 H.264/AVC 相比，AV1 编码还会增加内存使用量，导致应用程序崩溃，从而进一步阻碍移动设备的普及。

低复杂度编码器

优秀的编码器应兼顾视觉质量和计算复杂度。低复杂度编码有助于在中低端设备上实现 AV1 编码。

与 H.264/AVC 等较旧的编解码器相比，AV1 等较新的编解码器具有更高的压缩效率。然而，这些优势通常以更高的计算复杂度为代价，这阻碍了 AV1 在低端设备上的应用。

然而，新的编解码器并不一定需要更复杂的编码器。由于现代编解码器支持更多编码工具，设计良好的编码器有更多机会在质量和复杂度之间找到更佳的平衡点。这些平衡点也称为预设。理想情况下，编码器应提供多个预设，涵盖从高到低的复杂度范围，同时保持稳定的压缩效率提升。例如，与 H.264/AVC 相当的超低复杂度预设，可以让 AV1 出现在低端手机上。 

为了解决这个问题，我们针对 RTC 应用场景采用了低复杂度的AV1编码器实现。除了优化高复杂度预设的质量外，我们还开发了一种超低复杂度预设。这种新的预设实现了与H.264/AVC相当的编码复杂度。基于此，我们设计了一种机制，可以根据设备性能调整编码器预设，从而使我们能够将AV1应用于更广泛的设备。

解码器选择

选择编码器之后，下一步是选择解码器。虽然视频解码器通常比编码器简单，但我们发现，在移动设备和视频通话场景中，解码的复杂度仍然很高，尤其是在低端机型上。在我们最初的A/B测试中，一些低端设备无法进行实时解码，导致视频卡顿和音视频同步问题。

我们对比了几款开源解码器，经过A/B测试后，最终选择了dav1d，因为它具有更高的能效和可靠性。实验结果也表明，使用dav1d解码器后通话时间有所延长。

二进制大小

将 AV1 编码器和解码器集成到移动应用中会带来另一个挑战：二进制文件大小。以 libAOM 为例，AV1 支持会使应用增加 1.7 MB 的大小（压缩后为 600 kB）。虽然这听起来微不足道，但对于服务数十亿用户的公司来说，这却是一个巨大的挑战。二进制文件大小会影响更新成功率、应用启动时间和软件健康指标（例如内存使用率和崩溃率），从而对用户体验产生负面影响。更大的二进制文件会导致更多用户继续使用旧版本应用，并延迟来电建立。例如，600 kB 的增加可能会耗尽大型组织一整年的二进制文件大小预算。

我们探索了几种减小二进制文件大小的方法。 

• 我们最初的想法是使用动态下载框架将 AV1 作为独立组件进行分发。然而，无论是网络状况不佳、设备问题还是随机事件导致的下载失败都会降低用户体验，使得这种方法无法满足需求。
• 接下来，我们专注于直接优化二进制文件的大小。例如，量化矩阵（QM）工具约占编码器库大小的10%；优化后可以将其减半。此外，我们还为dav1d项目贡献了减小文件大小的优化方案。

这种策略延伸至端到端流水线优化，彻底从库中移除未使用的工具。例如，移除 QM 可以释放 60 kB 的二进制空间。在应用层面，我们可以跨功能共享编解码器库（例如视频消息转码），并利用平台内置的编解码器支持，避免捆绑额外的库。

扩大 AV1 覆盖范围

在选定编码器和解码器之后，下一个挑战是确定哪些设备符合使用 AV1 的条件。由于 iOS 机型数量有限，确定符合条件的 iOS 机型相对容易，但由于 Android 设备型号数量庞大，这带来了更大的挑战。

我们最初尝试根据内存、发布年份和安卓操作系统版本来选择设备，但这些策略都不够可靠。最终，我们利用 Meta 自主研发的基于机器学习的设备资格框架，生成了一份可靠的符合条件的安卓设备列表。

AV1 设备资格

我们创建了一个基于机器学习 (ML) 的设备资格框架，以根据设备功能支持高级视频和音频功能：

我们的理念是利用大规模的真实世界统计数据对设备功能进行分类，而非依赖实验室数据。这有助于我们扩展设备资格认证系统并做出更准确的决策。我们提出了一种基于机器学习的设备资格认证方法，该方法利用通过日志管道收集的底层性能统计指标来评估设备的 AV1 功能。该模型将这些测量值作为输入特征，并输出一个 rtc_score 值，该值量化了设备的整体 AV1 性能。该分数可用于指导诸如优化通话设置以及判断设备是否能够高效运行 AV1 编解码器等决策。

2025 年，我们利用 AV1 专用数据迭代优化了模型，并显著扩展了设备支持范围。我们的第一个里程碑版本模型 V1.1 于 2025 年 8 月发布，扩大了 AV1 流量在更多设备上的覆盖范围。新增流量促成了专用AV1数据集的建立，该数据集随着时间的推移规模不断扩大，代表性也更强。基于这些更丰富的数据，我们构建了模型 V2，引入了双层架构，区分高端设备和低端设备。这反映了入门级手机和旗舰设备在AV1编码能力方面可能存在显著差异的现实。在这些迭代过程中，我们大幅提升了AV1在各种设备上的启用率，并采用一种旨在随着流量增长和更多数据的出现而持续改进的方法。 

随着 AV1 流量的持续增长，我们预计迭代优化将进一步提高通话时长和通话质量。

编解码器复杂性自适应

设备资格认证使我们能够识别出符合要求的设备，但我们也发现了一个额外的挑战：在 A/B 测试期间，我们观察到通话中存在严重的音视频同步问题，这主要是由于设备无法实时编码或解码视频造成的。令人惊讶的是，即使是配备八核处理器的 2023 年智能手机也无法处理 320×180@15fps 的编码。这个问题同时影响了 H.264 和 AV1 编码，但 AV1 编码更为普遍。我们怀疑这些设备在通话期间会降低 CPU 频率，从而降低了其有效性能。

因此，仅根据设备名称启用 AV1 是不够的。我们需要一种更强大的机制，能够根据本地设备和对等设备的状态来调整编解码器的复杂度。我们开发了三种机制：自适应编码器预设调整、编码延迟感知编解码器切换和解码延迟感知编解码器切换。

自适应编码器预设调整

我们设计了多种编码器预设，复杂度从低到高不等。监控机制会持续跟踪调用期间的编码延迟，以选择合适的预设。如果编码延迟过高（意味着设备接近无法实时编码），我们会降低编码器复杂度。相反，如果设备能够承受更高的复杂度，我们会提高预设复杂度以获得更好的编码质量。

本地设备编码延迟感知编解码器开关

如果降低编码器预设值后编码延迟仍未降至合适水平，我们将进行编解码器切换。在这种情况下，设备会切换到 H.264/AVC，对于特定内容而言，H.264/AVC 的计算量可能低于 AV1。为了实现这一点，我们在通话建立时协商对两种编解码器的支持，客户端会持续监控设备状态以确定最合适的编解码器。编码器预设值和编解码器选择是共同决定的，以优化通话质量并防止编解码器选择频繁切换。

对等设备解码延迟感知编解码器开关

由于 AV1 的解码复杂度更高，我们需要确保对端设备能够实时解码 AV1 帧。这一点在高端手机呼叫低端手机时尤为重要：发送方可能能够编码 AV1，而接收方可能无法实时解码。

为了解决这个问题，每个设备都会在通话期间持续反馈其视频解码延迟。如果发送方检测到对端无法实时解码 AV1，则会切换回 H.264/AVC。

这些机制协同作用，根据编码和解码延迟自适应地调整编码器预设和编解码器。除了延迟之外，我们还会考虑其他设备健康状况信号，例如电池电量。例如，当电池电量低时，我们会切换到 H.264/AVC 编码。这有助于保持通话质量并延长通话时长。

非对称编解码器设计

通过改进编解码器选择策略，我们将 AV1 支持扩展到了中低端 Android 设备。虽然部分中端设备无法进行实时 AV1 编码，但许多设备可以实时解码 AV1。这使得非对称编解码器设计成为可能：中端设备继续编码和发送 H.264/AVC，但可以接收来自高端设备的 AV1 信号。因此，我们显著提高了 AV1 在 Android 设备上的覆盖范围。

提高 AV1 通话质量

前几节介绍了我们在各种设备上启用 AV1 的框架。有了这套系统，AV1 现在已为 MetaRTC（实时通信）应用中的大多数移动设备提供支持。接下来的挑战是进一步提升 AV1 通话质量。

如前所述， RTC 产品必须在通话过程中动态适应网络状况。其中两个显著的​​挑战是网络带宽波动和丢包。精确的速率控制有助于应对带宽变化。容错策略在确保丢包情况下仍能提供可靠的通话质量方面发挥着重要作用。

精确的速率控制

在 RTC 中，保持恒定比特率（CBR）至关重要。任何瞬时比特率过冲都可能导致对端网络拥塞和视频卡顿。RTC 应用对瞬时比特率过冲非常敏感，因此仅仅检查平均比特率是不够的。我们使用视频缓冲验证器（VBV）延迟作为评估 CBR 准确性的指标。

VBV 延迟

视频缓冲验证器 (VBV) 是一种基于漏桶的测量方法，用于确保编码后的视频流能够在解码器处正确缓冲和播放。

我们采用类似的方法来测量基于案例推理（CBR）的速率控制精度。下图展示了一个示例：

假设当前分配给视频的网络带宽为 100 kbps，我们要求编码器以 100 kbps 的速率对帧进行编码。编码器以 20 kbps 的速率对帧 (Frm) N 进行编码。同时，帧 (Frm) N-1 尚未完全传输，缓冲区中还剩余 5 kbps 的数据（可能是由于帧 N-1 的过冲造成的）。

因此，发送帧 N 至少需要 (20 kbps + 5 kbps) / 100 kbps = 0.25 s = 250 ms。考虑一个系统中，RTC 的期望 VBV 延迟低于 200 ms 。在这个例子中，编码器过冲和较大的 VBV 延迟很可能导致糟糕的用户体验，例如更高的延迟、网络拥塞或视频卡顿。这凸显了精确速率控制对于 RTC 应用场景的重要性。

码率控制优化

我们对码率控制进行了多项改进，以确保编码器不会出现过冲现象。编码过程中，编码器会跟踪 VBV 缓冲区状态，并以此指导码率分配。当出现过冲时，编码器会降低后续帧的码率，从而控制 VBV 延迟。根据我们的经验，许多视频编码器无法很好地处理这种情况，导致 VBV 延迟不断增加，并可能造成网络拥塞。

类似地，编码器通常会为帧内（关键）帧分配较高的比特率，以保持关键帧和帧间帧之间的质量一致性。有些编码器甚至会“提升”关键帧的质量，以提高参考帧的质量。然而，在 RTC 中，我们需要避免比特率峰值。因此，编码器会严格控制关键帧的比特率，并降低后续帧的码率来补偿任何过冲。

RTC 中的码率控制也面临挑战：

• 目标比特率频繁变化。客户端可能会频繁更新编码器的目标比特率。一个稳健的编码器必须能够有效控制VBV延迟，尤其是在目标比特率急剧下降时。
• 频繁的分辨率变化。客户端在通话过程中也可能频繁更改分辨率。因此，码率控制算法在频繁的分辨率变化下应保持稳定有效。此外，AV1 支持一项名为参考图像重采样 (RPR) 的实用功能来解决这个问题，该功能允许在不生成关键帧的情况下更改分辨率。这可以显著降低比特率峰值并改善视频卡顿现象。

由于视频编码器与网络拥塞控制模块密切交互，我们发现防止欠冲与防止过冲同等重要。在我们早期版本的码率控制算法中，我们采用保守的码率分配来避免过冲，但这反而增加了欠冲的倾向。欠冲会误导带宽估计，减缓码率上升速度，并最终降低视频质量。因此，我们改进了算法，以解决欠冲问题并提高码率精度。

总的来说，能够产生稳定码率（没有明显的过冲或欠冲）的精确码率控制算法可以显著提高视频通话质量。

错误恢复能力

RTC 对延迟有严格的限制，而现代视频编解码器则依赖于帧间紧密的依赖关系链。当数据包丢失时，接收方必须发送否定确认 (NACK) 并等待一次往返的重传。如果重传失败，依赖关系链就会断裂，视频画面会冻结。接收方随后会请求关键帧，这又需要一次往返，但由于关键帧的大小大约是典型 P 帧的 10 倍，它们会造成网络拥塞并增加丢包率，从而形成恶性循环。为了缓解这个问题，我们利用时间层 (TL) 和长期参考 (LTR) 帧，对 AV1 进行了优化，使其能够在丢包情况下快速恢复并抑制漂移。

时间层（TL）

时间层是现代视频编解码器（包括 AV1）中使用的一种时间可扩展性形式，编码器将帧组织成基于时间的层次结构。基础层（时间层 0）本身提供较低的帧速率，而增强层（时间层N）则在条件允许时添加中间帧以达到更高的帧速率。图 4 显示了我们用于 AV1 的双层结构。

这种结构的一个显著特点是，基础层无需依赖增强层帧即可保持连续性。即使增强层数据包丢失或到达过晚，解码仍然可以利用基础层继续进行，而不会中断。我们利用这一特性，按层优先考虑鲁棒性：我们采用前向纠错（FEC）来保护基础层数据，而不是将冗余资源用于增强数据。此外，我们对增强层重传的处理也更为保守，当往返时间（RTT）较短时，重传丢失的增强层数据包会有所帮助；而当RTT较长时，我们可能会跳过重传，而不会中断解码流程。

这里存在权衡：与紧密依赖的预测链（其中每一帧都引用紧邻的前一帧）相比，时间层结构通常压缩效率较低，因此始终启用时间层可能会在给定比特率下降低质量。但时间层的优势主要体现在有损或不稳定的网络环境下，而这仅占实际通话场景的一部分。因此，我们采用自适应的方式启用时间层。发送方监控网络反馈，在丢包率上升时启用时间层，并在网络状况恢复后将其关闭。这样，我们就能在需要时获得弹性，同时在不需要时不会牺牲效率。

长期参考值（LTR）

LTR 是一种容错功能，它允许视频编码器在缓冲区中存储比常规参考帧更长的参考帧，并根据请求发送 LTR 预测帧（LTRP）。当解码链因丢帧而中断时，根据先前解码的 LTR 帧预测的传入 LTRP 帧会立即重新同步发送方和接收方，从而恢复丢帧。图 5 展示了 LTR 和 LTRP 帧在无损和有损场景下的工作原理。

实现 LTR 需要与网络层紧密协作。图 6 展示了 AV1 编码器如何与网络层交互。编码器周期性地发出 LTR 帧，并将其固定在大小为 4 的有限参考缓冲区中，当添加新的 LTR 帧时，会移除最旧的已固定 LTR 帧。然而，从网络层的角度来看，编码后的 LTR 帧与其他帧并无二致，因此网络无法判断何时向编码器发送 ACK。为了确保可靠性，编码器在将帧传递给网络层时会发送一个显式的 LTR 指示符。这与 H.264 不同，H.264 通过比特流语法来区分 LTR 和非 LTR 参考帧——网络层可以解析 H.264 切片头来识别 LTR 帧，并在收到后向发送方发送 ACK。

显式 LTR 指示符是一个二进制标志，存储在我们专有的 RTP 报头扩展中，用于在主信道上传输帧级元数据。我们还通过 LTR 比特流语法将frame_id暴露给网络层。ACK 反馈通过另一个专有的 RTP 报头扩展发送。每个 ACK​​ 都包含相应的frame_id ，使发送方能够明确识别接收到的 LTR。在处理 LTRP 请求时，编码器始终使用最近收到的 ACK LTR 作为预测参考。

网络层在两种情况下会向编码器请求 LTRP 帧。第一种是被动恢复，即接收方遇到网络冻结并发送 RPSI 请求 LTRP 帧。第二种是主动保护，即发送方通过反馈通道检测到丢包率升高，并请求编码器定期发送 LTRP 帧。虽然主动保护路径可能存在一定的冗余，但它能显著提高网络可靠性并减少网络冻结。从编码器的角度来看，请求原因并不重要。它只是接收到 LTRP 请求，并根据缓冲区中是否存在已确认的 LTR 引用来做出响应。如果存在 LTR，编码器会生成 LTRP 帧。否则，它会假定需要重新同步，并发送一个关键帧。

虽然 LTR 在丢包恢复方面比强制关键帧或依赖重传更有效，但它会降低整体编码效率，因为 LTRP 帧可能引用时间相关性较弱的旧 LTR，从而降低运动预测的准确性。我们利用编码器现有的设计特性来缓解这个问题。编码器本身会周期性地发射一个质量略高的帧来提升整体质量。我们只需将该帧标记为 LTR，这样即使 LTR 帧老化，也能保持高质量。

Meta 与 AV1 的持续合作

Meta 在实时通信采用 AV1 是一项历时多年的努力，涵盖了编解码器选择、设备兼容性、速率控制和纠错机制等多个方面。通过将低复杂度编码器与基于机器学习的设备兼容性、自适应编解码器切换和强大的纠错机制相结合，我们已在大多数移动设备上启用了 AV1，显著提升了通话质量，尤其对带宽受限网络的用户而言更是如此。这项举措是对我们持续推进 AV1 在视频点播 (VOD) 应用领域应用的补充。随着设备性能的不断提升和机器学习模型对更多数据的利用，我们预计 AV1 的覆盖范围和通话质量将持续进步。

与此同时，我们正在努力将 AV1 扩展到群组通话。与一对一通话不同，群组通话的参与者需要解码多个视频流，这使得在群组通话中扩大 AV1 覆盖范围更具挑战性。虽然软件 AV1 实现有助于 AV1 覆盖范围的稳步扩展，但更高质量和更完善的功能可能需要 AV1 硬件支持。

AV1 的优势显而易见，大多数内容和实时通信服务提供商都已将 AV1 作为其旗舰编解码器。我们鼓励 SoC 厂商在所有设备层级投资硬件 AV1，以满足 AV1 的要求，从而提升用户观看体验、节省设备电池电量并提高网络运营商的基础设施效率。