RTC @scale 2024 | 通过LTR和RS码增强实时通信 (RTC) 网络弹性

引言

近年来，随着 RTC 使用量的显着增长，在网络状况不佳的情况下时常发生数据丢包。数据包丢失在计算机网络中是常见现象，也是网络弹性面临的主要挑战之一。在 RTC 环境中，数据恢复不仅应该实时进行，还要利用尽可能减少带宽的占用。在视频中，作者深入探讨了如何增强视频网络在丢包场景下的弹性。

视频卡顿

作者将视频卡顿视为衡量通话连贯程度的指标。由于原始视频数据巨大，需要进行编码（即压缩）后才能通过网络传输。在基本 RTC 设置中，视频帧可以编码为关键帧或 P 帧。关键帧较大，但可以独立解码，而P帧虽较小，但其解码需要可解码的参考帧。当数据包丢失破坏 P 帧解码链时，视频会持续卡顿，除非修复该码链（通过重传）或启动一个新链（使用关键帧）。从主动的角度来看，为码链提供备份链路，即前向纠错（FEC），可以防止链断裂。

在典型的 RTC 视频网络弹性设置中，重传、关键帧和 FEC 协同工作来防止视频卡顿。在过去，优化这三个机制已经显著地提升了服务质量；然而，这并没有阻止下一代技术的发展：长参考帧 (LTR) 和里德-所罗门码 (RS 码) 前向纠错 (FEC)。

Figure 1:Video freeze caused by packet loss

现有解决方案

重传

当接收方检测到序列号间隙时，它会请求发送方进行重传。尽管重传对于某些网络非常有效，但有两种情况其效果不佳：

1. 高往返时间 (RTT)：在完全恢复之前，视频会明显停顿，而 FEC 可以缓解这种情况。
2. 突发丢失：相较于恢复每个丢失数据包的高带宽，恢复关键帧的开销较小。

前向纠错 (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 是一项功能，允许编解码器将某些帧保留在内存中，以用作对未来帧进行编码的参考。此概念用于各种视频编解码器，包括 H.264、H.265 (HEVC) 和 VP8。

LTR 提供了一种有效地从损失中恢复的新方法。如图 2 所示，如果解码器由于第 5 帧中丢失数据包而被阻塞，则接收器可以根据其收到的最新可解码 LTR（在本例中为来自帧3）来解码帧 7。

Figure 2: How LTR help with video freeze with packet loss

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

Figure 3: Key frame on the left. LTR-P on the right.

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

高层设计

图 4 展示了 LTR 的高层设计。基本上，LTR 通常通过运行以下过程来工作（对于硬件和软件 H.264 编码器）：

1. 编码器周期性地生成 LTR。
2. 标识 LTR 及其依赖性的唯一令牌将发送到接收者，并确认可解码的 LTR 帧。
3. 在需要时，编码器会生成引用已确认的 LTR 帧的 LTR-P。

虽然高层设计看起来很简单，但需要解决一些挑战才能使其发挥作用。以下是部署 LTR 时遇到的一些挑战：

Figure 4: System diagram for the LTR design

在 META 部署 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 来纠正此问题。此后，便不再观察到 LTR 的长期卡顿问题。

围绕关键帧进行优化

虽然成功实现了 LTR 的无缝运行，但由于随着时间的推移开发了许多关键帧特定的优化，它的部署也面临许多问题。一个特别重要的问题是 LTR-P 期间出现明显的音频/视频 (A/V) 同步回归，但关键帧不会发生这种情况。深入分析表明，该问题源于专门的优化，该优化清除了关键帧传输后的重传列表，从而显著增强了 A/V 同步。缺乏对 LTR 的优化导致了明显的 A/V 同步差异。此场景举例说明了需要确定已应用于关键帧的优化和修复，以确保 LTR 包含类似的功能以实现相同或卓越的性能。

通过克服这三个挑战，LTR 成功部署，且没有影响任何主要质量指标。这导致丢包情况下关键帧减少了近 20%，而没有出现任何视频卡顿。

RS码视频 FEC

除了基于 XOR 的 FlexFEC 之外，结合 Reed-Solomon 纠错码大大提高了视频流在丢包恢复方面的性能。优势不仅体现在基准测试上，还体现在生产测试中的视频卡顿指标上。

基于异或的开源 FEC 解决方案

WebRTC 为基于 XOR 的 FEC（例如 FlexFec 和 ULPFEC）提供了成熟的实现。它们都使用启发式规则来覆盖不同的数据包丢失场景，并且作为开源解决方案效果相当好。然而，有两个缺点促使 Reed-Solomon 码 FEC 的使用：

1. 高流量开销：基于 XOR 的 FEC 需要大量带宽才能实现可接受的丢包范围。媒体流量经常遭受低质量和低分辨率的振荡。
2. 恢复率欠佳。对于 k 个源数据包，基于 XOR 的 FEC 理论上需要

个保护数据包来保证恢复。

Figure 5: K parity packets cannot recover k lost packets

基于异或的 FEC 无法扩展

假设在视频和 FEC 之间按 50/50 分配带宽，则对于 k 个视频数据包，有 k 个由 XOR 编码的 FEC 数据包。这也称为（k，2k）编码。

每个 FEC 数据包可以恢复

个丢失场景，总共有

个丢失场景。因此，基于 XOR 的 FEC 的恢复率受

限制。当 k 超过 5 时，恢复率呈指数下降。换句话说，随着现代 RTC 应用程序演变成更高的媒体质量和更高的流量，基于 XOR 的 FEC 无法扩展。

RS码 FEC 具有良好的可扩展性

RS 码具有比基于 XOR 的视频 FEC 更优越的属性。使用相同的（即 k、2k）编码，RS 代码具有恒定的 100% 恢复率，并且随着流量速率的增加而无限扩展。

Figure 6: RS code workflow

将RS码部署到 META Messenger

Meta 使用内部专有的 Reed-Solomon 代码实现来为其 RTC 视频 FEC 算法提供支持。为了在移动客户端上部署 RS 代码，需要对实现算法、编解码器配置、编解码器内存优化和编解码器运行时的优化做仔细的决定。

作者精心设计了现有网络弹性 (NR) 系统的集成，以便 RS 代码和 FlexFec 可以动态地相互切换并与时间分层兼容。

总结并展望未来

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

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

附上演讲视频： 视频地址