Adopting AV1 for Real-Time Communication (RTC) at Scale

在 Meta 的大规模实时通信（RTC）中采用 AV1 —— Meta 工程实践

发布日期

2026 年 6 月 22 日

分类

Android

,

iOS

视频工程

在大规模实时通信（RTC）中采用 AV1

.entry-meta

.entry-header

作者

Yu-Chen (Eric) Sun

Jie Dong

Kewei Huang

Dave Jack

Joachim Reiersen

Phil Scherbel

Karthik Sekuru

Vertika Singh

Thileepan Subramaniam

Wei Zhou

• 在 Meta 采用 AV1 进行实时通信是一个持续多年的努力，涵盖了编解码器选择、设备适配性、码率控制和错误恢复等多个方面。

• 我们将分享在部署 AV1 和扩展覆盖范围过程中遇到的技术和运营挑战，以及我们如何解决这些问题以提升实时通信的质量。

• 我们将介绍几种用于提升 AV1 通话质量的技术，包括码率控制和错误恢复。

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

为什么 Meta 愿意在 RTC 中采用 AV1？

转向更先进的视频编解码器的动机是显而易见的 —— 它在使用更少带宽的同时提供了相同的视觉质量。在离线测试中，我们观察到在低端和中端设备上，与 H.264/AVC 相比，使用 AV1 可以实现至少 20% 的比特率降低。如果设备能够处理更高的编码复杂度，比特率的降低甚至会更大。对于实时视频通话来说，这意味着在网络速度较慢或带宽受限的情况下，用户可以享受到显著更好的视频质量。这对我们的用户来说非常重要，因为为了满足低延迟的要求，RTC 产品必须处理比特率波动。在现实世界的网络环境中 —— 尤其是在新兴市场 —— RTC 产品的视频比特率通常在 10 kbps 到 400 kbps 之间。在低于 100 kbps 的情况下保持良好的视频质量仍然是一个挑战。

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

https://engineering.fb.com/wp-content/uploads/2026/06/Meta-AV1-RTC-Demo.mp4

H.264/AVC（左）与 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 应用于低端设备的障碍。

然而，新的编解码器并不一定需要更高复杂度的编码器。由于现代编解码器支持更广泛的编码工具，设计良好的编码器可以找到更多在质量和复杂度之间的平衡点。这些平衡点也被称为预设（presets）。理想情况下，编码器应提供多种预设，从高复杂度到低复杂度，同时保持一致的压缩效率提升。一种与 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 由于设备型号众多，带来了更大的挑战。

我们最初尝试根据内存、发布年份和 Android 操作系统版本来选择设备，但这些策略都没有被证明足够可靠。最终，我们利用 Meta 内部基于机器学习（ML）的设备资格框架，生成了一份可靠的符合资格的 Android 设备列表。

AV1 设备资格

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

图 1：我们的基于机器学习的设备资格框架。

这个想法是使用大规模的真实世界统计数据来分类设备能力，而不是依赖实验室数据。这有助于我们扩展设备资格系统并做出更准确的决策。我们提出了一种基于机器学习的设备资格方法，该方法使用通过我们的日志流水线收集的低级性能统计指标来评估设备的 AV1 能力。该模型将这些测量值作为输入特征，并输出一个 rtc_score，该分数量化了设备的整体 AV1 性能。这个分数随后用于指导决策，例如优化通话设置以及确定设备是否可以高效运行 AV1 编解码器。

在 2025 年，我们使用 AV1 特定的数据对模型进行了迭代优化，并大幅扩展了设备支持范围。我们的第一个里程碑，Model V1.1，于 2025 年 8 月推出，并在越来越多的设备上扩展了 AV1 流量。这些额外的流量随着时间推移，形成了一个更大且更具代表性的专用 AV1 数据集。借助这些更丰富的数据，我们构建了 Model V2，引入了两层方法，区分高端和低端设备，反映了入门级手机和旗舰设备在 AV1 编码能力上可能有非常大的差异。在这些迭代过程中，我们在设备范围内大幅提高了 AV1 的启用率，采用的方法旨在随着流量增长和更多数据的可用性而持续改进。

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

编解码复杂度适应

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

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

#### 自适应编码器预设调整

我们设计了多个编码器预设，从低复杂度到高复杂度不等。一个监控机制持续跟踪通话中的编码延迟，以选择适当的预设。如果编码延迟变得过高——这意味着设备接近无法实时编码——我们会降低编码器的复杂度。相反，如果设备能够维持更高的复杂度，我们会提高预设，以实现更好的画质。

#### 本地设备编码延迟感知的编解码器切换

如果降低编码器预设仍然无法将编码延迟降低到适当的水平，我们会应用编解码器切换。在这种情况下，设备会切换到 H.264/AVC，这可能比 AV1 对于特定内容的计算强度更低。为了实现这一点，我们在通话建立时协商双方对这两种编解码器的支持，并且客户端持续监控设备状态以确定最合适的编解码器。编码器预设和编解码器的选择是联合决定的，以优化通话质量并防止编解码器选择的震荡。

#### 对端设备解码延迟感知的编解码器切换

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

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

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

#### 非对称编解码器设计

随着改进的编解码器选择策略，我们向中端和低端 Android 设备推出了 AV1 支持。虽然一些中端设备无法实时编码 AV1，但许多设备可以实时解码 AV1。这使得非对称编解码器设计成为可能：中端设备继续编码并发送 H.264/AVC，但可以接收来自高端设备的 AV1。因此，我们显著提高了 Android 设备上 AV1 的覆盖范围。

图 2：非对称编解码器设计。

提高 AV1 通话质量

前面的章节描述了我们在各种设备上启用 AV1 的框架。有了这个系统，AV1 现在在 Meta RTC（实时通信）应用中驱动了大多数移动设备。下一个挑战是进一步提高 AV1 通话质量。

如前所述，RTC 产品必须在通话期间动态适应网络状况。两个显著的挑战是网络带宽的波动和数据包丢失。精确的码率控制有助于应对带宽变化。在存在数据包丢失的情况下，容错策略在确保可靠质量方面发挥着重要作用。

精确的码率控制

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

#### VBV 延迟

视频缓冲验证器（VBV）是一种基于漏桶模型的测量方法，用于确保编码后的视频流可以在解码器端正确缓冲和播放。

我们采用类似的方法来衡量 CBR 率控制的准确性。下图是一个示例：

假设当前分配给视频的网络带宽为 100 kbps，并要求编码器以 100 kbps 的速率对帧进行编码。编码器以 20 kbits 的速率对帧（Frm）N 进行编码。同时，帧（Frm）N-1 尚未完全传输，缓冲区中还剩下 5 kbits（可能是帧 N-1 出现了超出）。

因此，发送帧 N 至少需要 (20 kbits + 5 kbits) / 100 kbps = 0.25 s = 250 ms。假设系统中 RTC 的目标 VBV 延迟低于 200 ms。在这种情况下，编码器超出和较大的 VBV 延迟很可能会导致较差的用户体验，例如更高的延迟、网络拥塞或视频冻结。这突显了 RTC 使用场景中准确率控制的重要性。

图 3：VBV 延迟计算的示例。

#### 率控制优化

我们进行了多项率控制改进，以确保编码器不会超出。在编码过程中，编码器会跟踪 VBV 缓冲区状态，并利用它来指导比特率分配。当发生超出时，它会减少后续帧的速率，以保持 VBV 延迟在可控范围内。根据我们的经验，许多视频编码器在处理这个问题时表现不佳，允许 VBV 延迟增长，从而可能引起网络拥塞。

同样，编码器通常会为仅包含帧内（关键）帧分配较高的比特率，以保持关键帧和帧间帧之间的质量一致性。一些编码器甚至会“增强”关键帧的质量，以提高参考帧的质量。然而，在 RTC 中，我们希望避免比特率峰值。因此，编码器严格控制关键帧的比特率，并减少后续帧的速率，以补偿任何超出。

RTC 中的率控制还面临以下挑战：

• 频繁的目标比特率变化。客户端可能会频繁更新编码器的目标比特率。一个健壮的编码器必须在控制 VBV 延迟方面表现良好，尤其是在目标比特率急剧下降时。

• 频繁的分辨率变化。客户端在通话过程中也可能频繁更改分辨率。因此，率控制算法在频繁分辨率变化下应保持稳定和有效。此外，AV1 支持一种有用的特性，称为参考图像重采样（RPR），它允许在不生成关键帧的情况下进行分辨率更改。这可以显著减少比特率峰值，并改善视频冻结问题。

由于视频编码器与网络拥塞控制模块紧密交互，我们发现防止比特率不足与防止比特率超出一样重要。在我们早期版本的率控制算法中，我们使用保守的比特率分配以避免超出，但这增加了比特率不足的可能性。比特率不足可能会误导带宽估计，减缓比特率的提升速度，最终降低视频质量。因此，我们对算法进行了修改，以解决比特率不足问题并提高比特率准确性。

总体而言，一种能够产生稳定比特率的精确码率控制算法——避免显著的过冲或下冲——可以显著提高视频通话的质量。

错误恢复能力

RTC 对延迟有严格的限制，而现代视频编解码器依赖于长而紧密的帧间依赖链。当一个数据包丢失时，接收端必须发送 NACK 并等待一次往返时间以进行重传。如果重传失败，依赖链就会断裂，视频将冻结。接收端随后请求一个关键帧，这又需要一次往返时间，但由于关键帧的大小通常是普通 P 帧的约 10 倍，它们可能会导致网络拥塞并增加数据包丢失，从而形成一个恶性循环。为了解决这一问题，我们通过利用时间层（TL）和长期参考（LTR）帧，对 AV1 进行了优化，以在数据包丢失的情况下实现快速恢复和漂移控制。

#### 时间层（TL）

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

图 4：两层时间结构。

这种结构的一个显著特性是，基础层可以保持连续性，而无需依赖增强层的帧。如果增强层的数据包丢失或到达太晚，解码仍可以使用基础层继续进行，而不会出现停滞。我们利用这一特性，通过按层优先考虑鲁棒性来提高可靠性：我们使用 FEC 来保护基础层数据，而不是将冗余用于增强层数据。我们还对增强层的重传采取更加保守的策略——当往返时间（RTT）较低时，重传丢失的增强层数据包可能会有所帮助；当 RTT 较高时，我们可能会跳过重传，而不会影响解码流程。

存在一个权衡：与紧密依赖的预测链（每个帧都引用前一帧）相比，时间层结构通常压缩效率较低，因此始终启用 TL 可能在给定比特率下降低视频质量。但 TL 的优势主要体现在有损或不稳定的网络环境下，而这些环境仅占现实世界通话中的一部分。因此，我们对 TL 进行了自适应启用。发送端监控网络反馈，当丢包率上升时启用 TL，当条件恢复后再次关闭 TL。这使我们在需要时获得恢复能力，而在不需要时不会牺牲效率。

#### 长期参考（LTR）

LTR 是一种错误恢复功能，允许视频编码器将参考帧在缓冲区中存储的时间比普通参考帧更长，并按需发送 LTR 预测（LTRP）帧。当由于帧丢失导致解码链断裂时，一个来自先前解码的 LTR 帧的 LTRP 帧可以立即重新同步发送端和接收端，从而从丢失中恢复。图 5 展示了 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 时。第二种是主动性保护，当发送端通过反馈通道检测到数据包丢失率升高时，会请求编码器定期发送 LTRPs。虽然主动性路径可能会有些冗余，但它显著提高了可靠性并减少了冻结。从编码器的角度来看，原因并不重要——它只需接收到 LTRP 请求，并根据缓冲区中是否有已 ACK 的 LTR 参考帧进行响应。如果有可用的 LTR，编码器将生成一个 LTRP 帧。如果没有，则认为需要重新同步，并发送一个关键帧。

虽然 LTR 在丢失恢复方面比强制发送关键帧或依赖重传更高效，但它可能会降低整体编码效率，因为 LTRP 帧可能引用一个较旧的 LTR，其时间相关性较弱，从而导致运动预测不够准确。我们通过利用现有的编码器设计选择来缓解这一问题——编码器已经定期发出一些稍高质量的帧以提高整体质量。我们只需将这些帧标记为 LTR，这样即使 LTR 变老，其质量仍能保持较高水平。

图 6：AV1 编码器与网络层的交互。

Meta 在 AV1 上的持续探索

在 Meta，将 AV1 用于实时通信是一个持续多年的努力，涵盖了编码器选择、设备兼容性、码率控制和错误恢复等多个方面。通过结合低复杂度编码器、基于机器学习的设备兼容性判断、自适应编码器切换以及强大的错误恢复机制，我们已在大多数移动设备上启用了 AV1，为尤其是在带宽受限网络上的用户带来了显著的质量提升。这一举措与我们扩展 AV1 在 VOD 应用中的持续努力相辅相成。随着设备性能的不断提升和机器学习模型利用更多数据，我们预计 AV1 的覆盖范围和通话质量将持续提高。

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

AV1 的优势显而易见，大多数内容和实时通信（RTC）服务提供商都正在将 AV1 作为其主打编解码器。我们鼓励 SoC 厂商在所有设备层级上投资 AV1 硬件支持，以满足 AV1 的需求，从而提供更优质的观看体验、设备电池节省以及增强的网络运营商基础设施效率。