作者：Yu-Chen (Eric) Sun、Jie Dong、Kewei Huang、Dave Jack、Joachim Reiersen、Phil Scherbel、Karthik Sekuru、Vertika Singh、Thileepan Subramaniam、Wei Zhou。原文发表于 2026 年 6 月 22 日，来源 Engineering at Meta。中文翻译整理。
在实时通信（RTC）中采用 AV1，并不是把一个编解码库接进应用就结束了。Meta 为此投入了数年，工作跨越编解码器选择、设备准入、码率控制和抗丢包恢复。本文介绍这些技术与落地难题，以及我们怎样扩展 AV1 覆盖范围并提升通话质量。
AV1 由 AOMedia 于 2018 年首次标准化，随后迅速发展，获得了广泛支持。YouTube、Netflix 和 Meta 等公司已大规模使用 AV1 传输视频。Meta 在 2023 年率先为高端设备的视频通话引入 AV1，之后持续扩大适用设备范围，并改善通话体验。按本文发表时的情况，Messenger、WhatsApp 等 Meta RTC 应用已在大多数移动设备上启用 AV1。
阅读边界：文中的“我们”指原文 Meta 团队。覆盖范围和实验结果均属于原文发表时的产品、设备和配置，不是对其他系统的保证。本文没有复现实验，也没有执行编解码或生产操作。
为什么实时通信需要 AV1
采用更先进视频编码的动机很直接：以更少带宽提供相同的视觉质量。按照我们的产品设置，在低端与中端设备上的离线测试中，AV1 相比 H.264/AVC 至少降低了 20% 的码率。如果设备能够承担更高编码复杂度，节省幅度还会更大。
对于慢速或受限网络上的视频通话，这意味着更好的画质。实时通话为了控制延迟，必须应对码率波动。在真实网络，尤其是新兴市场中，RTC 视频码率通常处于 10～400 kbps，低于 100 kbps 时要保持良好画质仍然很难。
我们在 Messenger 中启用 AV1，用两部 Android 手机进行并排比较，把两侧都限制在 100 kbps。原文演示中，左侧 H.264/AVC 显得明显模糊，右侧 AV1 更清晰，展示了受限带宽下的优势。可查看 原文对比视频；本文没有把该演示改称通用基准结果。
屏幕共享等需求也越来越重要。计算机生成的画面包含大量文字和高频细节，传统视频编码器未必擅长，人们对模糊文字又非常敏感。AV1 的调色板模式（palette mode）和帧内块复制（intra-block copy）能显著改善这类内容的编码效率。
调色板模式利用这样一个特点：屏幕画面中的像素通常集中在有限种颜色上。因此，它可以传递颜色簇，而不必像常规方法那样表示量化后的变换域系数。同一幅屏幕画面里也常有重复图案，帧内块复制便可以在同一帧内进行块预测。AV1 在 Main Profile 中就提供了这两种工具。
RTC 与点播的约束不同
与视频点播（VOD）不同，RTC 要控制视频的端到端延迟，理想情况下低于 300 毫秒；超过这个范围，通话者就容易感到对话延迟。
高画质和低延迟并不容易同时满足。多遍编码可以改善质量，却增加等待；解码端大量缓冲也会推高延迟。即使平均码率合理，瞬时码率突增仍可能让通话冻结。
网络带宽和丢包情况还会在通话过程中变化。编码器会调整分辨率和帧率，但切换分辨率通常需要新的关键帧，容易造成码率尖峰和短暂卡顿。丢包又可能触发重传或请求新关键帧，同样会导致冻结。此外，移动客户端同时承担实时编码与解码，功耗也是不可忽视的约束。
先选对编码器与解码器
采用新编码格式时，选择实现是最关键的一步。AV1 用更先进的工具换来更好的压缩效率，也增加了计算需求，编码端尤其明显。
我们曾在一个离线实验中集成开源 AV1 编码器，在 Pixel 8 视频通话场景测量功耗。相比 H.264/AVC，功耗增加了 14%。这对移动端是明显障碍。后来采用的内部低复杂度编码器，功耗才接近 H.264 基线。AV1 编码还会增加内存使用，导致应用崩溃指标退化，这也使落地更复杂。
原文配套功耗表把开源 H.264/AVC 编码器归一化为 100%，开源 AV1 编码器为 114%，内部低复杂度 AV1 编码器为 97%。这与正文所述“接近 H.264 基线”一致，但仍只代表图表所对应的实验与实现。
低复杂度编码器
一个好的编码器，需要平衡视觉质量与计算复杂度。低复杂度实现是把 AV1 带到中低端设备的关键。
人们常把新编码格式带来的压缩收益，与更高复杂度绑定起来。但更新的格式并不必然要求更复杂的编码器。工具种类越多，设计得当的编码器反而越有机会找到更好的质量与复杂度折中。这些折中通常称为预设档位（preset）。理想的实现应提供从高到低的多个档位，并在不同档位维持压缩效率优势。
因此，我们在 RTC 的 AV1 实现中，除了优化高复杂度档位，也开发了一个超低复杂度档位，使计算复杂度接近 H.264/AVC。再根据设备能力动态选择档位，AV1 就可以覆盖更广的设备范围。
解码器
解码器一般比编码器轻，但在移动通话中，特别是低端机上，解码负担依然明显。最初的 A/B 测试发现，一些低端设备无法实时解码，造成视频冻结和音画不同步。
比较多个开源解码器并进行 A/B 测试后，我们选择了 dav1d，原因是它的能效和可靠性更好。实验还观察到了使用 dav1d 后通话时长增加的现象。
二进制包大小
编解码器还会扩大移动应用体积。以 libAOM 为例，加入 AV1 支持会增加约 1.7 MB，压缩后约 600 kB。对服务数十亿用户的应用，这并不小：体积影响更新成功率、启动时间，以及内存、崩溃等软件健康指标。
更大的安装包会让更多用户停留在旧版本，也可能推迟来电建立。在大型组织里，增加 600 kB 甚至可能耗掉一整年的二进制体积预算。
我们尝试过把 AV1 作为单独组件动态下载，但网络、设备问题或随机失败都会损害体验，因此仅靠这条路径不够。随后，团队转向直接缩减二进制：例如，量化矩阵（QM）工具约占编码器库大小的 10%，优化可让这部分缩小一半；我们也向 dav1d 贡献了体积优化。
优化还可以沿端到端管道展开：完全移除不用的工具，例如移除 QM 可释放 60 kB；在应用内让视频消息转码等功能共享编解码库；利用平台内置编解码支持，减少额外打包的库。这些数字描述原文实现，不能当作所有构建配置的固定体积。
怎样判断一台设备能否使用 AV1
确定实现后，下一个问题是设备准入。iOS 型号相对有限，整理适用名单较容易；Android 设备种类庞大，难得多。
我们先尝试按内存、发布时间和 Android 系统版本筛选，但这些方法都不够可靠。最终采用 Meta 内部基于机器学习的设备准入框架。
这个框架面向音视频高级功能，根据设备能力作决策。它不只依靠实验室数据，而是使用大规模真实使用统计，通过日志管道收集底层性能指标。模型把这些测量作为输入，输出 rtc_score，用来量化设备整体 AV1 表现，再决定通话设置及设备能否高效运行 AV1。
原文的框架图进一步展示了完整数据链路：采集 CPU、内存、相机和视频编解码等指标，预处理并归一化，结合已知设备表现标注历史数据，训练、验证和微调模型，再用离线推断生成设备评分，把评分用于通话设置与质量调整。
2025 年，我们持续用 AV1 专属数据改进模型。第一个里程碑 Model V1.1 于 2025 年 8 月推出，覆盖更多设备，新增流量又形成了越来越大、越来越有代表性的 AV1 专用数据集。
基于更丰富的数据，Model V2 引入两档方案，区分高端与低端设备，因为入门机和旗舰机的编码能力确实差别很大。随着流量与数据增长，这种迭代机制还可以持续改善设备覆盖、通话时长和质量。
设备获准进入，还要在通话中持续调整
设备名单只能解决第一层问题。A/B 测试中，我们观察到明显的音画同步退化，主要原因是设备无法实时编码或解码。甚至一款 2023 年发布、拥有八核处理器的手机，也可能无法处理 320×180、15 fps 的编码。
这个问题在 H.264 和 AV1 上都存在，只是在 AV1 上更常见。我们怀疑设备在通话中降低了 CPU 频率，使实际可用能力下降；这是原文的推测，而不是已证实的统一原因。
因此，单凭设备名称启用 AV1 并不够。我们建立了三种机制，根据本机和对端实时状态调整复杂度。
自适应调整编码预设
编码器有从低到高的多个复杂度档位。监控机制持续跟踪编码延迟。如果延迟过高、设备接近无法实时处理，就降低复杂度；如果设备能持续承担更高复杂度，则提高档位来改善质量。
根据本机编码延迟切换编码格式
如果降到较低档位后，编码延迟仍不合适，就切回 H.264/AVC。对某些具体内容，它可能比 AV1 更省计算。
为此，通话建立时会协商双方对两种格式的支持，客户端在通话中继续监控设备状态。预设档位与编码格式共同决定，既优化画质，也避免两种格式来回振荡。
根据对端解码延迟切换
高端手机能实时编码 AV1，并不代表接收它的低端手机能实时解码。因此，每台设备都会持续反馈视频解码延迟。发送端发现对端无法实时处理 AV1 时，就切回 H.264/AVC。
这些机制综合编码和解码延迟调整档位与格式。此外，我们也考虑其他设备健康信号，例如电量。在电量低时切换到 H.264/AVC，有助于维持通话质量和时长。
允许两个方向使用不同格式
这套策略让 AV1 得以扩展到中低端 Android 设备。一些中端机虽然不能实时编码 AV1，却能实时解码。因此，通话不必在两个方向使用同一种编码格式：中端机可以继续发送 H.264/AVC，同时接收高端机发送的 AV1。这种非对称设计显著扩大了 AV1 覆盖范围。
提高通话质量：准确的码率控制
扩大覆盖后，下一步是提高画质和稳定性。带宽波动与丢包是两个核心问题：前者需要准确的码率控制，后者需要稳健的错误恢复。
RTC 对恒定码率（CBR）很敏感。瞬时超出预算就可能造成拥塞和对端冻结，所以只看平均码率是不够的。我们使用 Video Buffering Verifier（VBV）延迟衡量 CBR 控制精度。
VBV 延迟意味着什么
VBV 是基于漏桶思想的度量，用来判断编码视频流能否正确缓冲并播放。我们用类似方法评估码率控制。
假设视频当前可用带宽为 100 kbps，也要求编码器按 100 kbps 工作。第 N 帧编码后为 20 kbits；与此同时，第 N−1 帧尚未传完，缓冲中还剩 5 kbits。那么，发送到第 N 帧末尾至少需要：
(20 kbits + 5 kbits) / 100 kbps = 0.25 s = 250 ms
如果该系统希望 RTC 的 VBV 延迟低于 200 毫秒，这个例子已经超出目标。编码超调和缓冲延迟可能带来更高延迟、网络拥塞或冻结。这里的 200 毫秒是示例系统目标，并非所有 RTC 系统的统一标准。
既防止超调，也防止不足
编码时，我们跟踪 VBV 缓冲状态，并据此分配码率。如果发生超调，就减少后续帧的码率，把延迟控制住。按我们的经验，不少编码器在这方面处理不佳，允许 VBV 延迟持续增长，最终可能造成拥塞。
关键帧也要特别处理。编码器常给帧内编码的关键帧分配更高码率，以保证它与帧间预测帧的质量一致；有些实现还会刻意提高关键帧质量，改善后续参考。但 RTC 需要抑制尖峰，因此我们严格控制关键帧码率，并让后续帧补偿可能出现的超调。
实时环境还存在两类频繁变化：
- 目标码率变化：客户端可能反复更新编码器目标，特别是码率骤降时，仍需控制 VBV 延迟。
- 分辨率变化：码率算法需要在频繁切换分辨率时保持稳定。AV1 支持的参考图像重采样（RPR）允许不生成新关键帧就改变分辨率，有助于减小尖峰和冻结。
编码器与网络拥塞控制模块紧密交互，因此码率低于目标的“欠调”也有害。早期算法为了避免超调，分配得过于保守，反而容易欠调。这会误导带宽估计，让码率上升变慢，损害视频质量。我们因此修改算法，同时处理欠调，提高码率精度。
有效的控制不是一味压低码率，而是在明显超调与欠调之间保持准确、稳定的输出。
抗丢包：别让依赖链轻易断掉
现代视频编码依赖长而紧密的帧间参考链。丢失数据包后，接收端先发送 NACK，等待一个往返时间来重传；如果重传失败，依赖链断裂，视频就会冻结。接收端接着请求关键帧，又需要一次往返。
按原文场景，关键帧大约是普通 P 帧的十倍，可能进一步造成拥塞和丢包，形成恶性循环。我们使用时间分层（TL）和长期参考帧（LTR），加快恢复并限制错误传播。
按网络条件启用时间分层
时间分层是一种时间域可伸缩编码：基础层，也就是 temporal layer 0，单独就能提供较低帧率；增强层加入中间帧，在条件允许时得到更高帧率。我们为 AV1 使用两层结构。
原文两层结构图用 0、2、4、6 表示基础层帧，并在其间加入 1、3、5、7 等增强帧；基础层链条仍可单独连续解码。
关键在于基础层不依赖增强层，因此增强层的数据包丢失或到达过晚时，仍可继续解码基础层，不必停顿。我们据此把前向纠错（FEC）重点用在基础层，而不是平均给增强层增加冗余。
增强层重传也更保守：往返时间（RTT）低时，补发丢失的增强层包可能有帮助；RTT 高时，可以放弃重传，而不破坏基础层的解码流程。
代价是压缩效率。相比每帧都参考紧邻前一帧的紧密预测链，时间分层通常不够高效，一直开启会降低给定码率下的画质。但它主要在丢包或不稳定网络下有价值，这只占真实通话的一部分。因此，发送端根据网络反馈自适应启停 TL：丢包上升就开启，网络恢复后关闭。
长期参考帧怎样帮助恢复
LTR 允许编码器比普通参考帧更长时间地保留某些参考画面，并在需要时发送根据它预测的 LTRP 帧。即使中间丢帧破坏了解码链，只要新的 LTRP 引用接收端此前已经解码的 LTR，就能重新同步双方，恢复视频。
实现它需要编码器与网络层密切配合。Meta 的实现定期生成 LTR，并把它固定在容量为 4 的有限参考缓冲区中；加入新 LTR 时淘汰最旧的已固定参考。
从网络层看，编码后的 LTR 与普通帧没有自然可区分的外观，因此网络层不知道何时应该向编码器回 ACK。编码器在把帧交给网络层时，会显式发送 LTR 标记。H.264 的情况不同：LTR 与普通参考帧可通过码流语法区分，网络层能够解析 slice header，识别 LTR 并在接收后确认。
在 Meta 的实现中，显式 LTR 标记是专有 RTP 头扩展中的一个二进制标志，与逐帧元数据一起走主通道。原文还说明，frame_id 通过 LTR 码流语法暴露给网络层。ACK 则通过另一种专有 RTP 头扩展返回，每条 ACK 都带有对应的 frame_id，让发送端明确知道哪个 LTR 已收到。这些是原文系统的具体协议设计，不能当成通用 AV1/RTP 必选格式。
处理 LTRP 请求时，编码器始终选择最近一个已获 ACK 的 LTR 作为参考。网络层在两种情况下请求 LTRP：
- 被动恢复：接收端已经冻结，通过 RPSI 请求一个 LTRP。
- 主动保护：发送端从反馈通道发现丢包上升，周期性请求编码器发送 LTRP。虽然可能增加冗余，但能改善可靠性、减少冻结。
编码器不必知道请求原因。它只检查缓冲区里有没有已确认的 LTR：有就生成 LTRP；没有则认为需要重新同步，改发关键帧。
相比强制关键帧或依赖重传，LTR 的恢复效率更好，但也可能降低整体编码效率。原因是较旧的参考帧与当前画面的时间相关性较弱，运动预测不够准确。我们利用已有设计减轻这个代价：编码器原本就会周期性生成略高质量的帧来改善整体画质，把这些帧标为 LTR，就能让长期参考即使变旧也保有较高质量。
接下来：群组通话与硬件支持
这几年的工作把低复杂度编码器、机器学习设备准入、自适应格式切换、准确码率控制与抗丢包机制结合起来，让 AV1 在 Meta RTC 的大多数移动设备上得以启用。带宽受限的用户尤其受益。
这也与 Meta 在 VOD 中扩展 AV1 的工作相互补充。随着设备能力提升、模型获得更多数据，覆盖范围和通话质量还有继续改善的空间。
团队还在把 AV1 扩展到群组通话。与一对一通话不同，群组参与者需要同时解码多路视频，所以扩大覆盖更困难。软件实现有助于逐步推广，但更高质量和更多功能，最终可能需要硬件 AV1 支持。
原文认为，AV1 的收益正在促使内容和 RTC 服务商把它作为主要编码格式，并呼吁 SoC 厂商在各档设备上投资硬件 AV1，以改善观看体验、电池使用和网络基础设施效率。
编辑核查：原文没有可执行代码；公式仅做算术与单位静态核对。20% 码率节省、Pixel 8 功耗增加 14%、包大小与关键帧倍数等均保留原场景，不扩展成普遍保证。配图为根据原文绘制的原创解释图，未冒充实测图表。原文权利归原作者及 Meta。
暂无评论内容