使用 LTR 和 RS 代码增强视频网络弹性 | 2024 RTC @SCALE

视频通话将人们聚集在一起，尽管他们之间存在地理距离。随着近年来 RTC 使用量的大幅增长，在网络性能不佳的情况下出现了新的挑战。

丢包在计算机网络中很常见，也是计算机网络弹性领域的一大挑战。就 RTC 而言，丢失恢复不仅要实时进行，还要尽可能少地占用带宽。在这篇博文中，我们将深入探讨我们最近针对丢包情况对视频网络弹性的增强。

作者：FAN ZHOU，FENGDENG LYU
原文：https://atscaleconference.com/enhancing-video-network-resiliency-with-ltr-and-rs-code/
实时互动网编译整理

视频冻结

用户无法忍受视频不流畅。视频冻结的增加与用户负面情绪的增加密切相关。我们将视频冻结视为衡量通话不流畅程度的指标。

原始视频数据非常庞大，因此在通过网络发送之前需要进行编码（即压缩）。对于基本的 RTC 设置，视频帧可编码为关键帧或 P 帧。关键帧较大，但可独立解码，而 P 帧较小，但其解码需要一个可解码的参考帧。

当数据包丢失导致 P 帧解码链断裂时，除非我们（通过重传）修复解码链或（使用关键帧）启动新的解码链，否则视频会一直冻结。从主动的角度来看，为解码链提供备份链接–前向纠错或 FEC–可以防止解码链断裂。

对于典型的 RTC 视频网络弹性设置，重传、关键帧和 FEC 可共同防止视频冻结。过去，对这三种机制进行优化可显著提高服务质量；但这并不妨碍我们跃向下一代技术：长期参考（LTR）帧技术和里德-所罗门码（RS 码）前向纠错（FEC）。

现有解决方案

重传

当接收方检测到序列号间隙时，会向发送方请求重传。重传在某些网络中非常有效，但在两种情况下重传会出现问题：

• 高往返时间（RTT）：视频在完全恢复之前会明显暂停。FEC 可对此进行补偿。
• 突发丢失：与恢复每个丢失数据包所需的高带宽相比，恢复关键帧所需的开销要小得多。

前向纠错（FEC）

当网络 RTT 较低时，重传的效果会很好，而如果抖动缓冲区不够长，无法让重传到达，重传的效果就会大打折扣。前向纠错（FEC）通过在发送原始数据的同时发送奇偶校验数据，实现瞬时丢失恢复。

当网络 RTT 较低时，重传效果很好，但如果抖动缓冲区不够长，无法允许重传到达，则重传效果较差。 FEC 通过与原始数据一起发送奇偶校验数据来实现瞬时丢失恢复。 

因此，视频FEC在RTC中具有广泛的应用：

• 带宽探测
• 主动保护（防止未使用的带宽）
• 反应性保护（来自媒体带宽）

WebRTC 提供了基于XOR的视频 FEC的可靠实现，该实现由 FlexFec 和 ULPFEC（不均匀级别保护前向纠错）包裹。从算法的角度来看，基于 XOR 的 FEC 有一个根本性的缺点：它不能很好地适应更多数据。随着保护组包含更多数据包，恢复性能呈指数下降。作为 MDS（最大距离可分离）代码，Reed-Solomon 代码具有更好的恢复特性，并且可以随着 RTC 流量的增长而无限扩展。 

关键帧

关键帧对于建立新的视频解码序列非常重要。它们在处理解码器故障和减轻灾难性损失事件方面发挥着重要作用。因此，关键帧在损失恢复中特别有效。关键帧能直接解除解码器的阻塞，从而无需重新传输所有丢失的数据包。例如，在可能需要重传多达 9 或 10 个数据包的突发丢失情况下，请求关键帧会更有效，因为一个关键帧可能只包含 2 到 3 个数据包。

然而，关键帧面临的一个重大挑战是其大小，通常比 P 帧大得多。这就造成了一个两难的局面：传输全尺寸的关键帧而不是 P 帧可能会加剧网络拥塞，而压缩关键帧可能会导致质量大幅下降。这种压缩会导致视频闪烁，可能会降低用户体验。

LTR 帧提供了一种可行的解决方案。它们在损失恢复方面的效率与关键帧相似，但体积更小，质量更好。在下一节中，我们将深入探讨 LTR 的概念和高级设计，探讨它是如何应对这些挑战的。

长期参考帧（LTR 帧）技术

LTR 帧是一种功能，允许编解码器在内存中保留一些帧，作为编码未来帧的参考。包括 H.264、H.265 (HEVC) 和 VP8 在内的各种视频编解码器都采用了这一概念。

LTR 提供了一种从丢失中恢复的高效新方法。如图 2 所示，如果解码器因第 5 帧丢失数据包而受阻，接收器可根据收到的最新可解码 LTR（本例中为第 3 帧）向发送器请求一个 P 帧（LTR-P）。接收方收到 LTR-P（来自第 7 帧）后，可根据第 3 帧的 LTR 继续解码第 7 帧。

与关键帧相比，LTR-P 尺寸更小，但质量更高。 LTR-P 可以比关键帧小 40% 到 50%，但它提供与 P 帧相似的视频质量（如果离 LTR 不是很远）。下图说明了关键帧和 P 帧之间的潜在差异：

鉴于质量差异，LTR-P 可以成为改善损失恢复的基础。不再需要对每个丢失的数据包进行重传；现在接收器可以根据最后可解码的 LTR 帧请求 LTR-P。在高损耗网络中，这比重传要高效得多。

高层设计

图 4 显示了 LTR 的高层设计。请注意，从根本上说，LTR 通常通过以下流程（硬件和软件 H.264 编码器）工作：

• 编码器定期生成 LTR。
• 向接收器发送识别 LTR 及其依赖关系的唯一标记。接收器向发送器确认可解码的 LTR 帧。
• 需要时，编码器会生成一个 LTR-P，该 LTR-P指向已确认的 LTR 帧。

虽然高层设计看起来简单明了，但要使其正常工作，我们还需要解决一些难题。下面，我们将介绍我们在部署 LTR 时面临的一些挑战。

在 META 部署 LTR 的挑战

虽然 LTR 被认为是关键帧的替代解决方案，但重要的是要了解 LTR 并不是关键帧的精确复制品。关键帧是完全可自解码的，而 LTR 仍然需要内存中存在相应的参考帧才能正确解码。这种区别意味着，如果没有覆盖任何边缘情况，可能会导致长时间没有视频。例如，在 LTR 的 A/B 测试中，我们观察到无视频速率显着下降（约 2%），这表明 LTR 与关键帧在丢包恢复能力方面仍然存在差距。以下是我们为成功推出 LTR 必须克服的一些主要挑战：

深入了解 OPENH264 的内部行为

OpenH264提供了全面的API支持来实现大多数与LTR相关的功能（例如LTR生成和确认），这极大地简化了我们的设计和实现过程。然而，在不彻底了解其底层工作原理的情况下应用这些 API 可能会导致部署挑战。例如，我们遇到的一个值得注意的问题源于内部编码器行为，该行为忽略 LTR-P 请求，生成 P 帧，直到生成关键帧后明确确认新的 LTR。这导致了死锁，接收方不断请求 LTR-P，而发送方则发送无法解码的 P 帧。我们通过重置 IDR 生成后编码器包装器中已确认的 LTR 状态来解决此问题。

了解 WebRTC 和 LTR 之间的交互作用

将 LTR 集成到 WebRTC 中非常复杂，需要详细了解 WebRTC 如何处理参照系。管理不善或理解不足都会造成问题。例如，我们最初是在收到帧后（帧解码前）发送 LTR 确认。但是，我们发现这样做偶尔会导致长时间冻结。后来我们发现，这些冻结是由于 LTR 在到达解码器之前被丢弃在帧缓冲区中，导致发送方根据不在接收方缓冲区中的 LTR 生成 LTR-P。我们通过在解码后才确认 LTR 来纠正这种情况。此后，我们不再观察到 LTR 的长时间冻结问题。

里德-所罗门码(RS 码) FEC

除了基于 XOR 的 FlexFEC 外，采用 Reed-Solomon 纠错码还大大提高了视频流的丢包恢复性能。这一优势不仅在基准测试中非常明显，在生产测试中的视频冻结指标上也有所体现。

基于 XOR 的开源 FEC 解决方案

WebRTC 为基于 XOR 的 FEC 提供了成熟的实施方案，如 FlexFec 和 ULPFEC。它们都使用启发式规则来覆盖不同的丢包情况，作为开源解决方案效果相当不错。然而，有两个缺点促使我们转向使用里德-所罗门码 FEC：

• 高流量开销：基于 XOR 的 FEC 需要大量带宽才能达到可接受的丢包覆盖率。媒体流量经常受到低质量和低分辨率振荡的影响。
• 恢复率欠佳。对于 k 个源数据包，基于 XOR 的 FEC 理论上需要 O(2^k / k) 个保护数据包才能保证恢复。

基于 XOR 的 FEC 无法扩展

假设视频和 FEC 的带宽各占一半，那么对于 k 个视频数据包，就有 k 个通过 XOR 编码的 FEC 数据包。这也称为 (k, 2k) 编码。

每个 FEC 包可以恢复 O(k) 种丢失情况，总共有 O(2^k) 种丢失情况。因此，基于 XOR 的 FEC 的恢复率以 O(k^2/(2^k)) 为界。当 k 超过 5 时，恢复率呈指数级下降。换句话说，随着现代 RTC 应用向更高媒体质量和更大流量发展，基于 XOR 的 FEC 无法扩展。

RS 码 FEC 具有良好的扩展性

与基于 XOR 的视频 FEC 相比，RS 码具有更优越的特性。在编码相同（即 k、2k）的情况下，RS 码具有恒定的 100% 恢复率，可随着流量的增加而无限扩展。

在 Meta Messenger 中部署 RS 码

Meta使用内部专有的 RS 代码实现来推动其RTC视频FEC算法。为了在移动客户端上部署里德-所罗门编码，我们对实现算法、编解码器配置、编解码器内存优化和编解码器运行时间优化进行了精心决策。

我们精心设计了与现有网络弹性（NR）系统的集成，这样 RS 代码和 FlexFec 就能相互动态切换，并与时序分层兼容。

结论和未来工作

当我们回顾在有损环境中提高视频流质量的历程时，我们为所实施策略的有效性感到鼓舞。我们在推出长期参考帧和里德-所罗门编码方面所做的努力为持续改进奠定了坚实的基础，并为未来的工作提供了宝贵的见解。

展望未来

处理数据包丢失的复杂性凸显了持续创新的必要性。显然，一刀切的方法是不够的，我们需要根据不同的用户场景和网络条件来调整我们的算法。未来需要改进的一些领域包括：

• 扩大 LTR 覆盖范围：我们计划将 LTR 支持从 OpenH264 扩展到其他编解码器，例如 AV1 和 iOS 硬件编码器，从而扩大我们在各种平台上的影响力。
• NR 方法的动态选择：我们当前的重点是将 LTR 集成为基本组件。我们渴望探索的一个有趣问题是如何将其与其他解决方案更有效地结合使用。例如，在不同的网络丢失和RTT场景下，我们应该如何决定何时请求LTR帧、关键帧或重传，以在视频卡顿和传输开销之间取得平衡？
• 视频 FEC：Meta 正在向上游 WebRTC 贡献其基于 XOR 的组呼叫 FEC 实现。业内的其他参与者可以利用我们的解决方案更好地扩展其群组呼叫应用程序。同时，我们仍在积极迭代视频FEC机制，以在不断变化的网络条件下保持竞争力。