突发数据包丢失对 WebRTC 音频质量的影响

在不太理想的网络条件下，确保 WebRTC 中的高质量音频遇到了关键的挑战，这主要是由突发的数据包丢失引起的。这种现象普遍存在于拥堵的网络、移动覆盖率低的地区以及公共 Wi-Fi 设置中。

在 WebRTC 框架内，有一系列策略可以缓解数据包丢失，但其效果因具体的网络动态而异。其中最普遍的技术包括：

• OPUS 前向纠错（FEC）：每个音频数据包都包含前一个数据包的低比特率数据，以便在丢失单个数据包时进行恢复。

• 数据包重传：利用标准的 NACK/RTX 机制，接收器在检测到数据包序列间隙时请求重传。

• 数据包复制：发送同一数据包的多个实例，目的是弥补可能的丢失。这就像发送抢先重传，以减轻潜在数据包丢失的影响。

• 冗余（RED）：这种技术需要在每个数据包中嵌入当前数据包的编码音频以及之前数据包的副本，通常采用 RFC2198 格式。

• 数据包丢失隐藏：采用各种隐藏技术，如时间音频拉伸或神经网络近似，以减轻数据包丢失的影响。

• 深度冗余（DRED）：集成神经网络编码器，在提供高质量编码的当前数据包的同时，提供比特率较低的先前数据包副本。

然而，这些技术的有效性取决于网络延迟和连续数据包丢失的程度。例如，重传在高延迟情况下会受到影响，而 OPUS FEC 和短 RED 模式在面对大量连续数据包丢失时则无效。因此，要确定最适合的方法以获得最佳效果，就必须辨别网络的特性。

分析真实网络中的数据包丢失突发情况

探索连续数据包丢失可为网络行为提供有价值的见解。这些突发在实际网络中的普遍程度如何？

传统上，回答这些问题是一项挑战。不过，随着为 Opus 1.5 版本开发的新网络模拟器的出现，并利用微软提供的数据，我们现在有了一个简单的工具，可以更容易地估计这些参数。

我使用该模拟器在不同的丢包条件下进行了一些测试，并提取了一些统计数据。下图说明了网络中相对于平均丢包百分比的丢包突发程度。

例如，在一个数据包丢失率为 1%的网络中，约有 16% 的丢失会导致一个以上的连续数据包丢失。因此，在这种情况下，采用 OPUS FEC 或单个数据包冗余等技术的效果可能会大打折扣。同样，在丢包率为 20% 的网络中，约 5% 的丢包涉及 5 个或更多连续丢包，因此我们需要增加大量延迟，才能在这些情况下利用冗余。

鉴于缓解技术的有效性取决于数据包丢失的性质，下一个逻辑问题就出现了： 我们如何辨别数据包丢失是否是突发的？传统的 RTCP 反馈可以提供平均丢失百分比的信息，但缺乏有关丢失模式的详细信息。为了解决这个问题，目前有几种方法：

• 假设突发数据包丢失：这种流行的方法假设数据包丢失间隙的长度与总体数据包丢失率相关。
• 传输控制中心反馈： 这种方法虽然不太常见，但它是根据传输拥塞控制反馈来测量突发率，提供了一种理论上合理的方法。
• RTCP 扩展报告 (XR)： 利用 XR 报告可明确包含有关数据包丢失突发的信息。

了解数据包丢失的突发性对于制定有效策略以减轻其对 WebRTC 音频质量的影响至关重要。

决定采用哪种技术是一个细致入微的问题，远非非黑即白。各种组合都可能有效，但在我看来，DRED、重传和 PLC 的组合可以在保持质量、管理延迟和优化不同网络条件下的比特率利用率之间取得平衡。我很想听听其他人在这方面的经验和见解。

作者：Gustavo Garcia
信息源自medium.