AV1 及更多…Jitsi Meet 如何选择视频编解码器？

Jitsi 博客最新的一篇文章表示经过彻底的实验和对实际性能数据的分析，AV1 视频编解码器将很快成为所有 Jitsi 部署中的默认首选编解码器，将其卓越的带宽效率和视频质量带给更广泛的受众。

Jitsi 于 2024 年 6 月引入了 AV1 支持，从那时起，它就一直在 Jitsi 的稳定软件包中提供。最初，必须通过config.js设置手动将 AV1 配置为首选编解码器，以允许用户选择加入。

在此基础上，AV1 很快成为meet.jit.si 上的首选编解码器，标志着其在利用先进压缩功能方面迈出了重要一步。从稳定版 9909开始，AV1 成为Jitsi Docker 部署中的默认首选编解码器，确保为选择容器化设置的用户提供开箱即用的支持。

向 Jitsi Meet 中的新默认视频编解码器 AV1 问好

AV1 编解码器代表了视频压缩技术的前沿。AV1 由开放媒体联盟 (AOMedia) 开发，该联盟由谷歌、微软、Netflix 和 Mozilla 等科技巨头组成，是一种无忠诚度的视频编解码器，旨在满足对高质量视频流日益增长的需求，同时最大限度地减少带宽使用。

与 VP9、VP8 和 H.264 等前代产品相比，AV1 的压缩率提高了 30-50%，可以在较低的比特率下实现更清晰的视觉效果。这使其成为带宽受限环境（如移动网络或网速有限的农村地区）的理想选择。尽管 AV1 功能强大，但由于多种因素，其采用速度比预期要慢。AV1 的计算需求更高，因为其先进的压缩算法需要更多的处理能力来进行编码和解码。AV1 的硬件加速仍处于新兴阶段，因此使用 AV1 可能会导致 CPU/能耗更高，并且在低端设备和没有硬件支持的设备中性能不佳。

在 Jitsi 中添加 AV1 支持的过程并不简单。在启用 AV1 之前，必须在 Jitsi Meet 客户端和 Jitsi Video Bridge (JVB) 中集成对编解码器提供的各种模式和复杂性的支持。Jitsi 必须扩展 JVB 的功能以处理 AV1 流，包括无缝管理多用户会议的联播和 SVC 模式。这项基础工作为 AV1 最终成为 Jitsi 部署中的首选编解码器奠定了基础。

与其他视频编解码器的 RTP 有效载荷相比，AV1 的 RTP 封装很不寻常，甚至有些奇怪——RTP 选择性转发单元 (SFU)（如 JVB）所需的所有信息都包含在“依赖描述符”RTP 标头扩展中，而不是 RTP 有效载荷本身中。这意味着 JVB 在技术上根本不需要支持 AV1 编解码器——它只需要支持依赖描述符标头扩展。

解码 AV1 的依赖描述符

这种格式很不寻常，因为它不是在 IETF 中开发的，而是由 AOMedia 自己开发的，而 IETF 通常定义 RTP 有效负载格式。这样做的主要结果是，标头的编码方式与视频编解码器非常相似：它非常节省比特使用量，但代价是解析起来非常复杂，而且是状态化的——解析标头所需的信息只会间歇性地发送。

一旦编写了一些实用程序类，处理复杂的解析就相对简单了。但是，处理状态性则比较困难，尤其是考虑到 SFU 始终需要为数据包丢失和重新排序做好准备，因此使用某些状态的数据包可能会在提供该状态的数据包之前到达。因此，这项工作需要跟踪携带该状态的数据包中报告的状态，并将其转发给解析器以解析后续标头，同时处理可能错过状态更新的可能性。

由于 AV1 DD 是标头扩展，因此它可以应用于除 AV1 本身之外的编解码器。值得注意的是，这使我们能够指示 H.264 流的时间可伸缩性，这很有用，因为 H.264（没有其很少实现的 SVC 扩展）无法指示其数据包的时间可伸缩性。因此，支持 AV1 DD 的工作还允许 Jitsi 为 JVB 介导的会议启用可扩展的 H.264 流！实际上，标头可以应用于任何视频编解码器，但我们仍然更喜欢在信息可用时使用它们的有效载荷信息来处理 VP8 和 VP9。

AV1 依赖描述符的另一个显著特点是其“解码目标”概念，即解码器可以解码的特定层，因此 SFU 可以转发该层。这些通常对应于特定的空间和时间层，但从技术上讲它们不必如此。这个想法是解码器可以在流中存在的各种解码目标中进行选择。在大多数情况下，它会选择可用的最高质量目标，但在某些情况下（例如，如果它受到 CPU 限制，或者在小窗口中显示源），它可能会选择质量较低的目标。

这就导致流需要明确说明实际存在的解码目标。根据设计，SFU 仅转发流中的某些层；这就是“选择性转发”的含义。因此，最终解码器需要知道它实际上可以预期接收哪些层，以及它不会接收哪些层，否则它可能会永远等待，而永远无法获得它认为应该渲染的帧。为了处理这种情况，AV1 依赖描述符在 AV1 标头扩展中包含一个解码目标位掩码，以指示哪些层仍存在于流中。然后，每次 SFU 更改其层转发决策时都需要更新此位掩码，这样解码器就不会尝试等待解码不再到达的解码目标，或者相反，这样它就可以知道开始解码新开始到达的新层。幸运的是，完成这项工作的逻辑并不太复杂，其复杂程度与修改前向 VP8 或 VP9 流的有效载荷信息所需的逻辑相似。

WebRTC 的可扩展视频编码 (SVC) 扩展

随着 Chromium M111 的发布，WebRTC 取得了重大进展，尤其是引入了可伸缩视频编码(SVC) 支持。此更新使 WebRTC 应用程序能够通过扩展RTCRtpEncodingParameters字典来配置 SVC 的编码参数。大约在同一时间，Chrome 还引入了 AV1 和 VP9 同步广播支持。在 Chromium M111 之前，K-SVC 模式（关键帧可伸缩视频编码）是 SVC 唯一支持的模式。此更新允许 Jitsi Meet 尝试 AV1 和 VP9 的各种可伸缩模式。

在 Jitsi 会议中，客户端和 JVB 协同工作以确保高效的视频流。这涉及发送方和接收方视频约束的持续交换。

接收方约束：每个参与者都会向 JVB 发送他们想要接收的视频流的约束（例如，所需的分辨率和优先级）。这些约束受参与者当前布局的影响（例如，为活跃发言者提供更大的图块）。
发送方约束：JVB 汇总这些约束并将所需的视频分辨率传达给发送方。这可确保参与者仅在至少有一位其他参与者在足够大的图块中观看时才发送更高分辨率的流（例如 720p）。

这种动态协调可最大限度地减少带宽使用量并优化网络资源，同时保持用户体验的质量。一旦客户端收到发送方约束，它就会使用RTCRtpEncodingParameters配置其出站视频流。这些参数是根据以下内容量身定制的：

分辨率：由JVB约束决定的有效分辨率。
视频类型：摄像头或桌面共享（进一步基于内容类型）。
编解码器操作模式：流是否使用完整 SVC、同步广播还是单播。

对于 AV1 和 VP9，测试了三种操作模式：

完整 SVC 模式：使用 L3T3（3 个空间层、3 个时间层）和 L2T3（2 个空间层、3 个时间层）可扩展模式。
K-SVC 模式：采用 L3T3_KEY 和 L2T3_KEY 可扩展性模式，专注于基于关键帧的可扩展性。
同步广播模式：用 L1T3（单个空间层、3 个时间层）配置每个同步广播层。

SVC 允许对单个视频流进行分层编码，每层为基础流添加更多细节或分辨率，而联播则涉及发送相同内容的多个独立视频流，每个视频流具有不同的分辨率和比特率。

经过广泛的性能测试和对产品要求的仔细评估，Jitsi 选择了完整的 SVC 模式作为 AV1 和 VP9 的默认配置。这一选择确保了 Jitsi 部署中的最佳可扩展性和视频质量。然而，这种行为并不是一成不变的；它是可配置的，可以通过config.js设置轻松覆盖，从而提供灵活性以适应特定的用例或部署需求。

选择“唯一”

为了确定 Jitsi Meet 客户端中使用的最佳视频编解码器，Jitsi 在现实条件下进行了全面测试，以确保编解码器选择能够满足产品对质量、性能和可扩展性的需求。以下是所涉及的方法和注意事项的概述：

测试场景

带宽变化：模拟涵盖低、中、高带宽环境。目标是评估每个编解码器如何在保持质量的同时管理网络波动。
延迟和数据包丢失：引入了不同程度的延迟和数据包丢失来评估编解码器的弹性。进行了压力测试以观察严苛条件下的行为，例如 30% 的数据包丢失或 300 毫秒的延迟峰值。
设备多样性：测试在一系列硬件上进行，包括 Windows 和 macOS 设备以及多种操作系统，以测量 CPU 负载和适应性。高端和低端系统均经过评估，以覆盖广泛的用户群。

捕获的指标

CPU 使用率：评估编码和解码性能，重点关注平均编码时间（以毫秒为单位）。数据来自出站 RTP 流中的totalEncodeTime统计数据，平均值是在测试运行中计算得出的。
带宽效率：记录提供可接受视频质量所需的最低比特率。分析每个编解码器的指标，以确定哪个编解码器在给定比特率下提供最佳质量。
可扩展性性能：测试每个编解码器处理空间和时间可扩展性的能力。捕获诸如切换延迟（适应新发送方约束的时间）等指标，以评估分辨率和帧速率变化时的适应性。
用户体验指标：监控丢帧和抖动以量化播放质量。测量网络中断或分辨率变化后的恢复时间，确保编解码器能够有效处理动态条件。

结果和观察

AV1：在低比特率下提供出色的视频质量，但需要更高的 CPU 能力（但在某些情况下令人惊讶地与 VP9 相当），使其成为现代设备上高质量会话的理想选择。事实证明，它是所有平台上屏幕共享的最佳编解码器，因为它使用屏幕内容编码来实现低比特率，同时不会影响视频质量并使用低 CPU。
VP9：平衡带宽效率和CPU使用率，对多方通话中的可扩展视频流有效。
VP8：在次优条件下表现出弹性，但与较新的编解码器相比，可扩展性和现代功能落后。
H.264：仅当支持硬件加速时，CPU 使用率才会最低。使用软件时，CPU 使用率会高得多，尤其是对于 4K 和屏幕共享等较高分辨率。在低带宽场景中，带宽效率和适应性也存在问题。

通过严格分析这些指标，Jitsi 优化了其编解码器选择策略。虽然全 SVC 模式仍然是高性能场景的默认模式，但为旧式或资源受限的设备配置了 VP9 和 VP8 等后备选项。这种全面的方法可确保 Jitsi Meet 客户端在各种设备和网络条件下提供最佳的视频体验。

使用 Jitsi Meet 中的自适应模式解决 CPU 过度使用问题

AV1 集成到 Jitsi Meet 后，用户可以享受到出色的压缩率和较低比特率下的高质量视频。然而，这些优势是以增加计算需求为代价的，尤其是在低端设备上。为了解决这个问题，Jitsi 引入了三重自适应质量控制机制，确保即使在 CPU 受限的情况下也能获得无缝体验。

适应性模式的工作原理

减少编码负荷
- 动态编解码器切换：在自适应模式下，Jitsi Meet 客户端会监控出站 RTP 流的 WebRTC 统计数据。如果统计数据表明存在 CPU 限制，客户端会反复切换到复杂度较低的编解码器。此过程会持续进行，直到达到复杂度最低的编解码器，具体取决于每种视频类型（例如摄像头馈送、屏幕共享）的预定义性能基准，从而降低视频编码的计算需求，而不会显著影响视频质量。
减少解码负载
- 请求更少的视频：如果降低编码复杂度还不够，客户端会向服务器请求更少的视频流。这会限制给定时间内活动的视频解码器的数量，从而降低 CPU 使用率。
- 降低接收视频分辨率：对于已接收的视频，客户端会请求降低分辨率，从而进一步降低解码要求。这有助于平衡计算负载，同时保持可接受的用户体验。

这种自适应方法使 Jitsi Meet 能够利用 AV1 的高级功能，同时确保具有不同硬件配置的用户能够参加会议，而不会因 CPU 使用率过高而造成中断。

但是，当 CPU 峰值源自外部进程而非 Jitsi Meet 客户端时，自适应模式可确保质量下降最小。为了增强用户体验，Jitsi Meet 还采用了恢复机制，一旦外部约束得到解决，即可恢复视频配置。

恢复机制

持续监控
- 客户端通过 WebRTC 指标监控浏览器报告的 CPU 限制统计数据。如果浏览器不再报告 CPU 限制，客户端将启动恢复序列。
增量恢复过程
- 恢复机制不断增加客户端向 JVB 请求的远程视频流的数量，直到达到会议设置的限制。
- 此过程是增量的，以防止 CPU 使用率突然飙升而导致客户端不稳定。
动态调整
- 如果在恢复过程中再次出现 CPU 限制，客户端将暂停进一步的恢复步骤。这可确保系统不会进入 CPU 使用率超出设备能力的状态。

这种循序渐进的方法可以最大限度地降低恢复期间系统过载的风险。它还可以适应波动的 CPU 可用性，保持性能和质量之间的平衡。客户端动态处理整个过程，无需任何用户交互，提供无缝体验。