数据包丢失会降低视频会议的用户体验质量（QoE）。在重传耗时过长的远距离通信中，恢复丢失数据包的标准方法是前向纠错（FEC）。传统的前向纠错方法在应对突发丢包时效率低下。然而，这类突发丢包在实际网络中频繁出现，而一类新的理论性FEC方案——称为“流编码”——能够以显著更少的冗余数据更有效地恢复突发丢包。然而，现有的流编码方案并未针对视频会议的需求进行设计，它们提升视频会议QoE的潜力也基本未经测试。Tambur 是一种基于流编码的新视频会议方法，克服了上述局限性。我们首先基于微软 Teams 的大量网络丢包数据进行仿真评估。与传统方法相比，Tambur 将视频帧解码失败的概率降低了 26%，同时将用于冗余的带宽减少了35%。我们用 C++ 实现了 Tambur，并将其集成到一个视频会议应用中，在模拟网络上对端到端的 QoE 指标进行了评估，结果显示多个关键指标均有显著提升。例如，Tambur 将视频卡顿的发生频率和累计时长分别降低了 26% 和 29%。

1 引言

      视频会议的通话质量决定了远程会议的效果[17]，而远程会议如今已无处不在。视频会议通话可以是一对一的[27]，也可以是多方的[39]。我们的工作侧重于一对一通话。视频质量取决于多个关键性能指标，例如卡顿、带宽、丢包和延迟[14, 28, 41]。恢复丢失的数据包对于提供高质量的视频会议至关重要[33, 48]。即使只丢失一个数据包，也可能导致一个视频帧无法渲染。此外，由于压缩视频的帧间依赖性，丢包还可能导致后续多个帧无法渲染（即造成视频卡顿）。正因如此，视频会议应用通常在应用层处理丢包。两种主要的可行解决方案是重传和前向纠错（FEC）。这两种方法都会传输冗余数据。因此，需要在分配给冗余的带宽与传输原始数据的带宽之间进行权衡。此外，视频会议应用必须在严格的延迟约束内恢复丢失的数据包——最好小于 150 毫秒[33]——以满足实时播放的要求。

       重传仅重新发送丢失的数据包，因此冗余数据量最小。所以在可能的情况下，重传是首选[64]。然而，由于视频会议应用严格的实时延迟要求，重传仅适用于往返时间较短的场景。在其他所有情况下，视频会议应用依赖 FEC 在可接受的延迟内恢复丢失的数据包。

       分组码是当今生产系统中最常见的 FEC 形式。在分组码中，使用 k 个“数据包”生成 r 个冗余包（称为“奇偶校验包”）。当这 (k + r) 个包中有一些丢失时，仍然可以恢复出 k 个数据包。有 r 个额外的奇偶校验包，因此带宽开销为 (r/k)×100%。设计 FEC 方案的一个主要目标是最小化带宽开销。分组码的常见例子包括 Reed-Solomon（RS）分组码[55]和喷泉码（即无速率码）[40]。许多码（例如 RS 码）对于独立丢失的随机丢包是最优的。例如，在上述例子中，如果使用 RS 码，任意 k 个包就足以恢复数据。因此，分组码在生产级视频会议应用中很受欢迎。例如，微软 Teams 就使用了 RS 码。

       视频会议应用将压缩视频帧的数据分到多个数据包中发送。我们将一个或多个连续帧上丢失多个数据包的情况称为“突发”丢包。突发丢包可能由多种原因引起，包括持续的 Wi-Fi 干扰和网络拥塞（当应用溢出路由器缓冲区并导致相关丢包时[29]）。我们对来自 Teams 数千次视频通话的数据包分析（§3.3）表明，视频会议应用面临的真实丢包确实是突发性的。

     在实时延迟要求下，分组码从突发丢包中恢复时的带宽消耗效率极低。相比之下，一种相对较新的理论性 FEC 框架，称为“流编码”[5,42,43]，能够高效地处理突发丢包并满足严格的延迟约束。从高层次来看，流编码根据每个数据包各自的播放截止时间顺序恢复突发中丢失的数据包，而分组码则按最早丢失数据包的截止时间同时恢复所有丢失的数据包。使用分组码进行丢包恢复会浪费在最后一个丢失包的截止时间之前发送的后续奇偶校验包。先前关于流编码的工作大多是理论性的[5,20,22,26,35,36,42,43,59–61]，研究界限和编码构造。少数现有工作[6,25]探索了流编码的实际应用，但仅限于 VoIP（即音频，而非视频）。

      鉴于带宽和丢包恢复的双重重要性，流编码对视频会议应用很有吸引力。然而，存在两个主要挑战。第一，现有流编码与视频会议应用之间存在差距。大多数实用的流编码变体[6,25]局限于输入数据大小随时间固定不变的场景。相比之下，在视频会议中，压缩视频帧的大小是可变的。唯一能够适应这种可变性的流编码[59–61]悲观地假设一个帧要么完全丢失要么完全接收，因为其框架涉及将每个帧放在单个数据包中发送。这在视频会议应用中很少成立。现有的流编码还要求每个突发之后都有一个保护间隔，其间所有数据包都被接收。但这一假设在实践中通常不成立（我们将在 §3.2 中展示）。此外，现有流编码使用理论信道模型的一个参数来设置冗余量，而该参数在实践中是未知的。第二，流编码对于改善真实视频会议应用的用户体验质量（QoE）的有效性尚未在真实数据上得到检验。

      本工作解决了上述挑战。我们提出了 Tambur，一种用于视频会议中带宽高效的丢包恢复的新型通信方案。Tambur 包含两个组成部分。第一，一种新的流编码，它建立在先前的理论框架[61]之上，同时克服了其在真实视频会议应用中的局限性。具体来说，Tambur 允许为每个帧指定带宽开销。此外，对于任何给定的带宽开销，Tambur 以一种方式创建数据包和奇偶校验包，这种方式 (a) 不过于悲观，能够从每个帧仅丢失部分数据包的突发中恢复，并且 (b) 对保护间隔中的丢包具有鲁棒性。第二，将该流编码与一个机器学习（ML）模型相结合，以预测性地决策分配给流编码的带宽。具体来说，采用了一种轻量级方法，仅使用一个简单模型和单比特的额外反馈。

我们分析了从 Teams 数千次视频通话中收集的数据包轨迹，并在 §3 中提出了三个关键观察：(a) 数据包突发丢包频繁发生。(b) 丢包之后通常（但并非总是）会跟随一个无丢包的若干帧的保护间隔。(c) 生产环境中使用的编码（RS 码）使用了显著的带宽开销来实时恢复丢包，从而挤占了原始数据的带宽。

      我们首先基于 Teams 的大量轨迹数据通过仿真评估 Tambur（§5.2）。我们将 Tambur 与 Teams 的 FEC（“Block-Within”，一种帧内分组码；§5.1）进行比较，结果表明 Tambur 以少 35.1% 的带宽开销多恢复了 26.5% 的帧。

图 1： 与 Block-Within 和 Block-Multi 相比，Tambur 在更低的带宽开销下，分别将每个视频中冻结帧占总帧数的比例降低了 78% 和 26%。

      我们还在我们自己开发的视频会议基准测试平台上实现并集成了 Tambur、几种基线方法（Block-Within 和 “Block-Multi”，一种跨多个帧的分组码）以及 Tambur 的几种变体（“Tambur-full-BW”，其带宽开销与 Block-Within 匹配；“Tambur-0.9”，进一步降低带宽开销但以恢复更少的帧为代价）。然后我们在模拟网络上对这些方案进行评估，以衡量其对 QoE 的影响（§5.4）。与 Block-Within 和 Block-Multi 中较好的一个相比，Tambur、Tambur-full-BW 和 Tambur-0.9 分别将视频卡顿的平均频率降低了 26%、29% 和 17%。图 1 显示这些优势在各个百分位数上均成立。这些优势凸显了 Tambur 改善了 QoE，因为已有研究[44,53,66]表明视频卡顿对用户参与度有不利影响。

总之，我们的主要贡献如下：

• 分析了从大型商业视频会议应用中获取的数千次视频通话的数据包丢包日志，并刻画了它们对使用流编码的适用性。据我们所知，这是首个利用大规模真实轨迹评估流编码潜力的工作。

• 提出 Tambur，通过 (a) 设计一种非常适合视频会议的新型流编码，以及 (b) 将其与轻量级机器学习模型相结合以预测性地决策分配给流编码的带宽，从而弥合了流编码理论与视频会议应用之间的差距。

• 实现了一个新的基准测试平台，以支持视频会议研究，并提供易于使用的接口来集成和评估新的 FEC 方案。此外，用 C++ 实现了 Tambur、Block-Within 和 Block-Multi，并使用该接口将它们集成到基准测试平台中。

• 通过仿真在大规模生产轨迹数据上评估 Tambur，结果表明它同时将不可恢复帧的频率和带宽开销分别降低了 26.5% 和 35.1%。

• 在模拟网络上评估 Tambur，结果显示在端到端 QoE 的关键指标上取得了显著改善（例如，将卡顿频率降低 26%，将卡顿累计时长降低 29%）。

                    图 2： 使用分组码的两种方式：(a) 在每个帧内部；(b) 跨多个帧。

总体而言，据我们所知，本论文是首个证明流编码能够改善视频会议 QoE 相关关键指标的工作。本论文还展示了一种新形式的 FEC——流编码结合基于学习的带宽分配——在视频会议中实现带宽高效丢包恢复的潜力。本工作不存在任何伦理问题。

2 背景与动机

2.1 传统 FEC 及其在视频会议中的挑战

分组码。 最常用的 FEC 之一是所谓的“分组码”。分组码的思想是将 k 个数据包 ⟨D[1],...,D[k]⟩ 编码为 r 个奇偶校验包，得到 ⟨D[1],...,D[k],P[1],...,P[r]⟩，从而可以使用 (k+r) 个包的子集恢复出 k 个数据包。当任意 k 个 (k+r) 个包都足以恢复时，该分组码称为“最大距离可分码”。最著名的 MDS 码例子之一是 Reed-Solomon 分组码 [55]。其他分组码的例子包括喷泉码（即无速率码）[40] 或二维分组码 [67]。

       传统上，FEC 应用于数据包，但视频会议中每个视频帧会传输多个数据包。一种自然的解决方案是对每个帧内的数据包应用分组码（图 2a）。奇偶校验包在一个帧的最后一个数据包之后立即发送。第二种方法是跨多个帧的数据包应用分组码（图 2b），即将所有奇偶校验包在块中最后一帧的最后一个数据包之后发送。我们对来自 Teams 的生产环境丢包轨迹（§3）的分析表明，数据包丢失是突发性的。这两种方法在处理突发丢包时都有显著的局限性。

分组码在视频会议中的局限性。 当数据包以突发形式丢失时，帧内方法会浪费在突发之后紧接的帧中发送的冗余，因为这些冗余对于恢复丢失的帧是无用的。尽管多帧方法克服了这一问题，但它有两个主要缺点。第一，恢复丢包的延迟较高，因为需要等待奇偶校验包（在块中最后一帧之后发送）来恢复任何数据包。分组码的长度必须很短，以免延迟超过播放一帧的实时截止时间，否则会导致带宽开销增加并对突发丢包的鲁棒性降低。第二，如果路由器缓冲区已满，快速连续发送的数据包可能会丢失。当路由器缓冲区已满恰好发生在某个块的最后一帧时，任何丢失的数据包都无法恢复。

        即使丢包率不高，FEC 奇偶校验包消耗的带宽也可能比重传高得多。与仅重传丢失数据包的重传不同，即使“最优”的 FEC 方案也无法预知哪些数据包会丢失。因此，它必须发送比丢失数据包多得多的奇偶校验包。例如，为了防止视频卡顿，大约每 150 毫秒必须至少发送一个奇偶校验包，以覆盖数据包丢失的情况。然而，如果没有丢包，这个奇偶校验包就不会被用到。

2.2 流编码

       有一类被称为“流编码”[5, 42, 43, 59–61]的编码方案，专门应对突发丢包以及发送方与接收方之间的顺序通信。从高层次上看，流编码通过以下方式避免了帧内编码和跨帧编码的局限性：(a) 在每个帧中发送奇偶校验包，(b) 利用突发中最后一帧的播放截止时间之前收到的所有奇偶校验包来恢复丢包。我们将详细描述流编码的理论框架，给出一个说明性示例，然后讨论为什么尽管框架与实践之间存在较大差距，流编码仍然是视频会议应用中一个很有前景的选择。

流编码框架包含以下内容：
(1) 发送方按固定时间间隔顺序生成数据包，并将数据包顺序传输给接收方。
(2) 一个对抗性的丢包信道，它会引入长度为 b 的突发丢包，随后是数据包成功接收的保护间隔。
(3) 要求接收方在规定时间内恢复丢失的数据包。在时间索引 i 到达的数据包必须在时间索引 (i+τ) 之前恢复。我们将参数 τ 称为“延迟截止时间”。一次突发丢包之后，保护间隔必须至少为 τ 个数据包（更长的保护间隔并不需要，因为突发丢包应在 τ 个数据包内恢复完毕）。

顺序编码。 流编码中编码的顺序特性非常适合视频会议，因为视频会议中需要周期性传输一系列压缩帧（例如，对于每秒 30 帧的视频，每 33.3 毫秒一帧）。我们将为第 i 个视频帧发送的符号记为 D[i]，每个符号可以看作一个比特向量。这些符号分布在一个或多个数据包中发送给接收方。此外，还有一些奇偶校验符号，记为 P[i]，也会在一个或多个数据包中传输。这些奇偶校验符号是过去若干帧数据符号的函数（线性组合）。

图 3： 使用流编码在延迟截止时间 τ = 3 内，恢复从帧 i 开始的 b = 2 个丢失帧。对于突发中的每一帧，在 τ 个数据包之后发送的所有奇偶校验符号用于恢复其丢失的符号。

顺序恢复。 在流编码模型下，延迟截止时间参数 τ 决定了恢复丢失数据包的延迟：如果 D[j] 丢失，它必须使用直到 P[j+τ] 的奇偶校验包中的符号来恢复。每个视频帧必须在严格的延迟内恢复，以便实时渲染。延迟截止时间参数 τ 根据帧速率和单向延迟来设置，以设定合适的最大延迟来恢复丢失的帧。例如，如果最大可容忍延迟为 150 毫秒（实时视频通信的标准值[33]），单向传播延迟为 50 毫秒，并且每 33.3 毫秒编码一帧（即 30 fps），则 τ 可以设置为 3（= (150−50)/33.3）。

图 3 展示了使用现有流编码（例如 [5,42,43]）在延迟截止时间 τ = 3 的情况下，对一个从帧 i 开始、长度为 2 的突发丢包进行顺序丢包恢复的示例。每个帧包含相同数量的数据。首先，突发后立即发送的数据包的奇偶校验符号恢复了每个丢失帧中三分之一缺失的数据符号（即 D2[i] 和 D2[i+1]）。其次，帧 i 和帧 (i+1) 中剩余的丢失数据符号（分别是 (D0[i], D1[i]) 和 (D0[i+1], D1[i+1])）使用帧 (i+3) 和帧 (i+4) 中发送的奇偶校验符号进行恢复。

      流编码通过在突发中每个帧的截止时间内顺序恢复这些帧来恢复突发丢包。对于一个涵盖 b 个连续帧 {i, ..., i+b-1} 的突发丢包，突发中的数据包 D[j] 使用 P[i+b], ..., P[j+τ] 的奇偶校验符号来恢复。这种顺序恢复的特性使得流编码能够利用截止时间内接收到的所有奇偶校验符号。例如，P[j+τ] 用于在 D[i]（i < j）的延迟截止时间之后恢复 D[j]。相比之下，分组码会同时恢复所有丢失的数据包。因此，恢复发生在第一个丢失帧的截止时间之前（即收到 P[i+τ] 的符号时），从而浪费了之后发送的奇偶校验符号。这一关键差异使得流编码能够实现显著更低的带宽开销；突发越长，流编码的优势就越大。然而，这也要求在突发之后至少有一个 τ 帧的保护间隔，否则某些帧可能无法在延迟截止时间内恢复。

2.3 使用流编码进行视频会议所面临的挑战

     将流编码用于视频会议存在两个主要挑战。第一，理论模型与实际系统之间的显著差距使得现有的流编码与视频会议应用不兼容。第二，流编码在视频会议中的有效性尚未在大规模真实轨迹上得到检验。因此，流编码能否改善视频会议应用的 QoE 仍是未知数。下面对这些挑战进行更详细的讨论。

现有模型与视频会议应用之间的差距。 现有的流编码实践工作 [6,25] 及其所依赖的理论工作 [5,42] 一样，都局限于每个时刻传输的数据量为固定常数的场景。然而，视频会议涉及发送压缩视频帧，这些帧的大小是变化的。只有少数流编码构造 [59–61] 能够处理这种可变性。然而，如 §2.2 所述，现有的流编码（包括 [59–61] 中的方案）考虑的是一个对抗性丢包模型，该模型施加了长度为 b 的突发丢包。当应用于视频会议时，参数 b 转化为连续多个帧的所有数据包都丢失的帧数。但是，视频会议应用通常每帧发送多个数据包，而且往往只有其中部分数据包会丢失，我们将在 §3 中对生产环境中的丢包轨迹进行更详细的说明。现有的流编码过于悲观，因为它们能够应对连续多帧所有数据包都丢失的情况。这一要求带来了显著的带宽代价，抵消了流编码潜在的带宽节省。此外，如果突发丢包之后的保护间隔内存在任何丢包，流编码也容易发生恢复失败。但在实践中，许多突发丢包之后并没有这样的保护间隔（参见 §3.2）。

流编码在真实环境中的适用性。 流编码在 VoIP 应用中的优势已经通过理论丢包模型（如 Gilbert-Elliott 信道 [23]）下的模拟丢包以及真实轨迹 [6,25] 进行了研究，这些研究中每帧以一个数据包发送，且所有帧/数据包大小固定。然而，这些结果并不适用于视频会议应用，因为视频会议 (a) 每帧发送多个数据包，(b) 每帧的数据量是变化的。当突发丢包跨越多个帧并且随后有一个无丢包的保护间隔时，流编码的性能最好。一个自然的问题是：这种丢包模式在视频会议中是否会出现，以及能否通过流编码加以利用？据我们所知，目前还没有基于大规模真实丢包的研究能够证明流编码在真实环境中的适用性。此外，要确立流编码能够改善 QoE，关键在于改善与 QoE 相关的多个指标。然而，现有文献中也同样缺乏对流编码在这些指标上影响的分析。最后，尽管帧间依赖在视频会议中普遍存在，但帧间依赖对流编码优势的影响尚未得到评估。

3 真实环境中的数据包丢失

     我们从微软 Teams 中收集了两周内随机抽样的通话日志（具体来说是数据包丢失记录）。其中一周的记录作为评估的测试集保留。Teams 仅在数据包丢失发生后才使用 FEC，这在业界是相当标准的做法 [64]，目的是为了避免为大量没有遇到任何丢失的通话浪费带宽。由于我们的重点是改善 FEC 被激活后的场景（即在第一次丢失后打开 FEC，然后用于恢复第二次丢失），因此我们将研究限制在至少发生两次丢失的轨迹上。我们的分析涉及约 9700 条轨迹，占所有轨迹的 16%。研究这些轨迹有助于揭示尾部性能，这对真实的商业应用至关重要。

      每条轨迹对应一次通话，包含每个接收到的数据包的大小、序列号、发送/接收时间戳，以及它是奇偶校验包还是数据包；丢失的数据包通过缺失的序列号来识别。由于应用的数据收集方法，轨迹仅限于通话的最后 60 秒。虽然日志是针对数据包的，但我们通过将日志与 Teams 的打包逻辑相结合来近似得到帧级信息，并且已与 Teams 工程师确认，这种近似是良好的。

3.1 FEC 指标

      Teams 在每个帧内采用 RS 分组码，并根据接收方反馈的数据包丢失情况（这种反馈不频繁）来调整带宽开销。我们将该应用使用的 FEC 方案简称为“Block-Within”。我们基于这些轨迹评估了三个指标。第一，每次视频会议通话中使用 FEC 的视频帧百分比（图 4a）。每条轨迹中使用 FEC 的视频帧百分比的第 25、50 和 75 百分位数分别为 13%、48.8% 和 70%，表明 FEC 应用于相当一部分帧。第二，每次视频会议通话中所有帧的视频帧解码失败百分比（图 4b）。帧解码失败百分比的第 25、50 和 75 百分位数分别为 0.6%、1.8% 和 6.1%。需要注意的是，为了提供高 QoE，解码失败率应保持在约 1% 以下 [33]。因此，解码失败普遍存在，足以切实地对 QoE 产生负面影响，这促使我们需要更有效的 FEC 机制。第三，每次通话的带宽开销（图 4c）。带宽开销的第 25、50 和 75 百分位数分别为 4.2%、24% 和 45%。因此，减少带宽开销将为这些通话释放相当一部分带宽。

图 4： 基于 Teams 轨迹的累积分布函数（CDF），分别展示 (a) 使用 FEC 编码帧以防止数据包丢失的频率，(b) 丢失数据包无法被解码的频率，以及 (c) 奇偶校验包的带宽开销。

3.2 网络质量

      我们分析数据包丢失情况，以评估流编码对真实视频会议应用的适用性。据我们所知，这是首个从这一角度分析大规模真实数据包丢失轨迹的工作。我们在图 5 中分析了丢包的三个关键指标：(1) 每条轨迹的数据包丢失率（图 5a）。(2) 在所有通话上测量的数据包突发长度分布（图 5b）。(3) 在所有通话上测量的帧突发长度分布（即至少丢失一个数据包的连续帧的数量）（图 5c）。该指标反映了流编码的适用性，因为当丢失数据包的突发跨越多个帧时，流编码最为有效（参见 §2.2）。

图 5： 数据包丢失现象突出（例如，图 5a 显示大多数轨迹的丢包率为 1%-10%），并且通常以连续数据包（图 5b）或连续帧（图 5c）的突发形式出现。

      轨迹中数据包丢失的平均百分比为 7%。这高于 FCC 报告中的丢包率 [15]，因为我们关注的是使用 FEC 的轨迹。如果也考虑 Teams 的其他轨迹，所有轨迹的平均丢包率为 1.7%，与 FCC 的测量结果相当。在早期的端到端互联网丢包研究中，丢包率往往随时间、ISP 和接入网络技术而变化 [8, 18, 24, 54]，ISP 的队列管理策略会影响应用所看到的丢包模式。如 [24] 所述，在家庭宽带网络中，丢包率在长时间内通常低于 1%，但会间或出现非常突发性的数据包丢失。在移动网络中也能看到类似的模式，切换期间丢包率往往会增加 [8]，并且会出现更长的数据包突发丢失。本节描述的来自 Teams 的轨迹显示了类似的行为：大量轨迹的丢包率非常低，而长尾轨迹则显示出极其突发性的数据包丢失。具体来说，38.1% 的丢包实例涉及至少两个连续数据包丢失（图 5b），38.4% 的丢包实例跨越了多个视频帧。这些丢包模式可以通过流编码高效恢复（§3.3）。

带宽开销（即用于奇偶校验包的带宽）与解码失败概率之间也存在权衡。带宽开销不能过高，否则原始数据的带宽将不足。因此，尽管使用了 FEC，帧解码失败的频率仍然不可忽视。

3.3 流编码的潜力

回顾 §2.3，流编码在以下情况下最为有效：(a) 数据包丢失以跨越多个连续帧的突发形式发生；(b) 突发丢包之后跟随一个由多个连续无丢包帧组成的保护间隔。我们形式化了两个指标来捕捉这些条件，然后证明轨迹中的丢包表现出这些特征。

测量突发。 解码一个突发所需的带宽开销取决于丢包跨越多个帧时丢失数据包的比例。我们引入一个新指标来形式化这一概念。

定义 1（多帧突发性） 假设一个突发跨越两个或更多帧（从帧 i 到帧 j），在此期间发送了 s 个数据包。如果其中 l 个数据包丢失，则多帧突发性定义为 l/s。

例如，假设 Tambur 分别在帧 i 和帧 (i+1) 上发送数据包 (D0[i], D1[i], D2[i]) 和 (D0[i+1], D1[i+1])。假设 D1[i]、D2[i] 和 D0[i+1] 丢失。那么多帧突发性为 3/5。由于突发中每个帧至少丢失一个数据包，因此多帧突发性始终为正。当突发中所有帧的所有数据包都丢失时，达到最大值 1。高值对应于多个连续帧中数据包丢失比例很高的情况。多帧突发性的值直接关系到任何编码实时解码有损帧所需的最小带宽开销。

测量保护间隔。 流编码可以在数据包突发丢失之后跟随至少 τ 个帧（τ 是延迟截止时间参数，见 §2）可靠传输的保护间隔的场景下，降低带宽开销。我们现在引入一个新的指标来衡量保护间隔满足这一特性的程度。

定义 2（保护间隔充分性） τ-保护间隔充分性是指：在一个或多个包含丢包的帧之后，至少跟随 τ 个连续无丢包传输的帧的实例所占的比例。

保护间隔充分性的值在 0 到 1 之间。它与使用流编码时所需的带宽开销呈负相关。保护间隔充分性的值越高，表明可以降低的带宽开销越大。

图 6： 基于轨迹的累积分布函数（CDF），分别展示 (a) 多帧突发性（针对至少有一个突发跨越 2 个以上帧的轨迹），以及 (b) 保护间隔充分性。

流编码的适用性。 我们在图 6 中基于轨迹评估了多帧突发性和 3-保护间隔充分性。在图 6a 中，多帧突发性的值在 0 到 1 之间变化，第 25、50 和 75 百分位数的值分别为 0.32、0.5 和 0.67。这表明使用流编码时所需的带宽开销随轨迹不同而变化，这与预期一致。对于较高的值，必须分配更多带宽用于冗余以解码丢包。对于较低的值，可以用较少的冗余带宽来实现。图 6b 展示了保护间隔充分性的评估结果，其第 25、50 和 75 百分位数的值分别为 0.73、1.0 和 1.0。这些值意味着流编码通常是适用的。例如，对于值为 1.0 的轨迹，每次发生跨越多个帧的突发时，本可以使用流编码以最优的带宽开销来解码丢包。然而，较低的值表明使用现有流编码降低带宽开销的保护间隔不足，因为现有流编码在保护间隔内发生丢包时很脆弱。

3.4 关键发现

      数据包突发丢失后跟随保护间隔的情况频繁出现，这有利于流编码的使用。然而，情况并非总是如此。有时突发之后跟随的保护间隔很短，或者涉及严重的数据包丢失，在这种情况下，无法通过流编码降低带宽开销。因此，将流编码集成到实际应用中需要：(a) 预测是否可以在不引起解码失败的情况下降低带宽开销，(b) 利用帧内的部分丢包（即每帧仅丢失部分数据包，而非全部），以及 (c) 增加对保护间隔内丢包的鲁棒性。

4 Tambur

       我们提出 Tambur，它通过以下方式利用 §3.3 中讨论的潜力，并解决 §2.3 中讨论的挑战：(1) 使用机器学习模型对带宽开销进行预测性决策；(2) 设计一种新的、适用于视频会议的流编码，能够适应任意设定的带宽开销。

      首先，一个机器学习模型对每帧分配的奇偶校验符号数量进行预测性决策。这有助于设定带宽开销以匹配网络条件。其次，奇偶校验符号的设计旨在提供：(a) 在利用部分丢包的同时，实现对跨越多个帧的突发的顺序恢复；(b) 对单个帧内偶尔发生的丢包进行即时恢复；(c) 对突发之后保护间隔内少量丢包的鲁棒性。第三，采用一种新的方法将每帧的数据和奇偶校验符号分布到多个数据包中。奇偶校验符号的设计及其在数据包间的分布共同构成了 Tambur 的流编码。在丢包恢复过程中，Tambur 使用从突发所涉及帧中接收到的数据包（即部分丢包），这使得它能够比忽略这些数据包的现有流编码实现更低的带宽开销。

图 7 展示了 Tambur 如何融入视频会议应用的协议栈。流编码器将压缩帧的数据编码为数据包和奇偶校验包。带宽开销预测器基于解码器观察到的丢包情况，使用预测性（机器学习）模型定期为每帧选择带宽开销，并将该值发送给编码器。流解码器使用奇偶校验包来恢复丢失的数据包。下面我们将详细描述这些组成部分。

                      图 7：Tambur 概览。绿色组件为 Tambur 所特有。

4.1 Tambur 的流编码

我们从编码和解码两部分来介绍该编码。

图 8：τ = 3 时的编码。Tambur 将帧 i 均匀分割为 (V[i], U[i])，并通过数据包发送。同时，Tambur 发送用于恢复 V[i-3]、...、V[i]、U[i] 和 U[i-3] 的奇偶校验包，并为帧 (i+3) 的奇偶校验符号预留空间。

编码。 我们以第 i 帧为例说明 Tambur 的编码方式。图 8 展示了 τ = 3 时的编码示例。该帧的数据符号 D[i] 通过数据包发送，奇偶校验符号 P[i] 通过奇偶校验包发送。在不超过 MTU（例如，在我们的实验中为 1500 字节）的前提下，数据包的大小被最大化并保持一致。带宽开销预测器先前输出的值决定了为第 i 帧分配多少个奇偶校验符号。这些奇偶校验符号将在 τ 帧之后发送（见图 8 中的“预留空间”）。为第 i 帧发送的奇偶校验符号数量由第 (i-τ) 帧的大小决定。

接下来，我们描述奇偶校验符号是如何生成的。P[i] 的符号是 (τ+1) 个帧 {D[i], ..., D[i-τ]} 符号的线性组合。为了定义奇偶校验符号，有助于将相关 (τ+1) 个帧的数据符号平均分为两部分，记为 D[j] = (V[j], U[j])，其中 j ∈ {i, ..., i-τ}。图 8 中分别用蓝色和绿色表示这些部分。

P[i] 的符号是 V[i], ..., V[i-τ]、U[i] 和 U[i-τ] 符号的精心设计的线性组合。具体来说，P[i] 是三个量之和：P[i] := P1[i] + P2[i] + P3[i]。P1[i] 的符号是 V[i-τ], ..., V[i-1] 符号的线性组合。P2[i] 的符号是 U[i-τ] 符号的线性组合。P3[i] 的符号是 U[i] 和 V[i] 符号的线性组合。所有线性组合都被精心选择为线性无关的线性方程。

解码。 我们将解码过程分为两部分：(1) 偶发性丢包；(2) 突发性丢包。

图 9：使用 Tambur 的流编码，在 τ = 3 帧的延迟内解码跨越 2 帧的突发丢包。标记为 1、2 和 3 的数据符号使用具有相同标记的奇偶校验包进行解码。

假设丢失之前的所有帧都已解码。首先，假设丢包很少发生，且 P[i] 的大小超过第 i 帧丢失的符号数。那么，P[i] 足以解码第 i 帧（具体来说，通过求解一个线性方程组）。

其次，考虑 τ = 3 时跨越两个连续帧的突发丢包，如图 9 所示。丢包（红色虚线边框）跨越了帧 i 和帧 (i+1)。对于每一帧 i，蓝色、绿色和棕色部分分别代表 U[i]、V[i] 和 P[i]。首先，V[i] 和 V[i+1] 都使用 P[i+2] 进行解码，P[i+2] 由 (a) V[i] 和 V[i+1] 的符号，以及 (b) V[i-1]、U[i-1]、U[i+2] 和 V[i+2] 的（已接收）符号的独立线性组合构成。其次，对于 j ∈ {i, i+1}，U[j] 使用 P[j+3] 进行解码，P[j+3] 由 (a) U[j] 的符号，以及 (b) V[j-3]、...、V[j] 和 U[j] 的（可用）符号的独立线性组合构成。该方法的关键在于，U[i+1] 不需要在 D[i] 的延迟截止时间（即 (i+3)）内恢复。这使得可以使用额外的奇偶校验符号（即 P[i+4]）来恢复 U[i+1]，同时仍然在 τ = 3 帧内解码每个数据包。附录 A 给出了通用情况。如果解码失败，接收方会请求发送方生成一个新的关键帧（即自包含帧）来处理帧间依赖关系。

      与现有的视频会议流编码相比，有三个关键区别：(1) 一帧的数据符号和奇偶校验符号通过多个数据包而非单个数据包发送。(2) 每帧的奇偶校验包的设计使其既可用于恢复之前发送的帧，也可用于恢复自身丢失的数据包。(3) 该编码足够灵活，允许使用带宽开销预测器为每帧设置带宽开销。

4.2 带宽开销预测器

      从高层来看，Tambur 使用一个预测模型来确定其流编码所采用的带宽开销（即图 8 中“预留空间”的大小）。该预测模型的输入是接收方定期（例如每两秒）计算得出的一个特征向量，称为“丢包模式报告”。预测模型的输出随后被发送给发送方，用于为 Tambur 流编码的每一帧设置带宽开销，直到收到下一份丢包模式报告。例如，50% 的带宽开销意味着如果第 i 帧包含 1000 字节，则将分配 500 字节的奇偶校验符号。

丢包模式报告。 设 P 为自上次丢包模式报告以来的数据包丢失位图，其中 1 表示丢失，0 表示接收成功。设 F 为自上次丢包模式报告以来，所有帧的位图，指示该帧是否至少有一个数据包丢失。丢包模式报告包含以下 13 个量，所有这些量都可以通过对 F 和 P 进行一次顺序遍历在线性时间内计算得出：

• 多帧突发性和保护间隔充分性（§3）。

• P 和 F 的丢包比例。

• P 和 F 的平均连续丢失次数。

• P 和 F 的平均保护间隔长度。

• P 和 F 的突发密度 [12] 和间隙密度 [12]。

• Teams 用于选择其带宽开销的分数，该分数基于观察到的数据包丢失比例和突发长度。

通过加权分类进行带宽开销预测。 Tambur 使用一个机器学习模型，根据最近的丢包情况来确定每帧分配的带宽开销。如上文 §4.1 所述，Tambur 的流编码允许对带宽开销进行细粒度调整，从而支持这种方法。为了保持模型简单，我们为带宽开销选择了两个选项。通过使用多类分类器来调整 Tambur 使用的带宽开销，这种方法可以轻松推广到两个以上的带宽开销值。在我们的实现中，我们使用了一个小型神经网络（在 §4.3 中进一步讨论），尽管任何方法都可以替代。

机器学习模型的训练对两个类别赋予不同的权重，具体取决于在节省带宽与最小化解码失败之间的优先级。本质上，对应于较高带宽开销的类别权重越高，帧解码的成功率就越高，但带宽开销的降低幅度就越小。视频会议服务运营商可以将这些权重用作调节旋钮，以优先减少解码失败或优先降低带宽开销。

神经网络细节。 二分类使用一个带有单个隐藏层的小型全连接神经网络进行。输入是最近 3 份丢包模式报告中 13 个指标的值。应用交叉熵损失，默认情况下，错误地降低带宽开销（即导致解码失败）和未能将带宽开销减半（即未能节省带宽）的权重分别设为 0.999 和 0.001。我们测试了不同数量的隐藏神经元（例如 100、1000 和 10000），并选择 1000 作为达到收益递减点的最小选项。该模型使用基于最优决策（在避免解码失败的前提下降低带宽开销）的轨迹，在 PyTorch 中进行离线训练和实现。在推理时，模型在 C++ 中实例化。

4.3 实现

我们用 C++ 实现了 Tambur，作为名为 Tambur 的新独立库的一部分，任何视频会议应用均可使用该库。在发送端，Tambur 以连续的压缩帧作为输入，并输出数据包和奇偶校验包。在接收端，Tambur 通过使用接收数据包的符号求解线性方程组来解码丢失的数据包。当数据包丢失时，我们将流编码的特性与开源的 min-cut/max-flow 算法 [11] 相结合，以在可忽略的时间内确定哪些数据符号可以使用哪些奇偶校验符号进行解码（参见附录 B）。然后，通过求解最小满秩线性方程组来解码数据。

我们使用一个小型头部来提供解码所需的帧级信息，包括数据包和帧的序列号，以及数据包在帧内和奇偶校验包中的相对位置。流解码器还需要丢失帧的大小才能对其进行解码（即使该帧对应的所有数据包都丢失了）；因此，我们使用流编码对帧大小序列进行编码，并在每个数据包中发送该编码的一个奇偶校验符号。

该库提供了一个接口，用于快速原型化新的 FEC 方案。我们使用该接口实现了 §1 中的基线方法（即 Block-Within 和 Block-Multi）。

线性编码和解码时求解线性方程组的核心算术运算使用 Jerasure 2.0 [52] 完成，这是一个 C/C++ 开源库，提供了擦除编码关键操作的模块。Jerasure 2.0 构建在 GF-Complete 库 [51] 之上，后者使用 Intel SIMD 指令快速执行伽罗瓦域算术。Tambur 将数据编码为 256 字节的“编码块”，每个块使用相同的线性方程组。将 Tambur 扩展到使用硬件卸载来编码和解码帧是未来工作的一个潜在方向。

与视频会议的集成。 为了验证 Tambur 在真实环境中的有效性，我们将其与 Ringmaster 集成。Ringmaster 是一个新的视频会议平台，用于模拟一对一视频通话，以对 FEC 方案进行基准测试。Ringmaster 使用约 4000 行 C++ 代码实现。其视频发送器以精确的帧速率（例如 30 fps）从磁盘上的输入 Y4M 视频文件读取原始帧，并使用 libvpx [1] 库中的 VP9 编码器，采用与 WebRTC [2] 类似的编解码器配置对帧进行压缩。用户提供的 FEC 方案为编码后的帧提供奇偶校验数据，这些数据被打包后通过 UDP 发送给视频接收器。收到帧后，视频接收器依次应用 FEC 解码器和 VP9 解码器来解码并渲染原始视频帧。此外，Ringmaster 允许请求新的关键帧，例如当接收方因数据包丢失过多而无法恢复视频帧时，会请求发送方编码一个新的关键帧以恢复视频播放。在自动通话结束时，通过聚合两个端点的日志计算 QoE 指标，这些日志记录了每个帧编码或解码时的时间戳，以及其帧 ID、大小、FEC 带宽开销等。

Ringmaster 提供了清晰且模块化的接口，我们用它来将 Tambur 集成进去。将 Ringmaster 与 Tambur 结合，可以通过 Tambur 的接口对 FEC 方案进行基准测试，评估其包含 QoE 指标（例如视频卡顿、每帧延迟、渲染帧率）的性能。此外，Ringmaster 还允许研究人员隔离 FEC 的影响，并禁用干扰 FEC 的模块，例如带宽估计 [13] 和数据包重传。

5 评估

为了评估 Tambur 能否改善用户体验质量（QoE），我们提出以下问题：

• Tambur 能否在与真实丢包相关的 FEC 指标上带来显著优势？

• Tambur 的这些优势能否转化为更高的 QoE？

5.1 实验方法与要点

视频会议应用参数。 在我们的实验中，我们将最大可容忍延迟设为 150 毫秒，以符合行业建议 [33]，这是交互式视频的一个相当标准的值。帧速率设为 30 fps，这是视频会议中的典型值。30 fps 的帧间到达时间为 33.3 毫秒。留出 50 毫秒的单向帧延迟后，解码延迟的余量约为 100 毫秒。因此，为了端到端延迟（即 33.3τ + 50）不超过约 150 毫秒，参数 τ 最多为 3（帧）。Tambur 的两个带宽开销选项是：与基线编码方案 Block-Within 的带宽开销相匹配，或使用其一半。Block-Within 将在下文介绍。

编码方案。 我们评估了六种编码方案。(1) Block-Within（图 2a），在帧内应用 RS 码。该方案被 Teams 在生产环境中使用。(2) Block-Multi（图 2b），在 (τ+1)=4 个帧上应用 RS 码。RS 码是最优分组码，因此上述两个基线在丢包恢复和带宽开销方面优于其他分组码（如喷泉码或无速率码）。(3) Tambur-full-BW，Tambur 的一个变体，其带宽开销与 Block-Within 相同。(4) Tambur-0.9，Tambur 的一个版本，其神经网络在训练时通过将损失函数中错误分类的权重从 0.999 降低到 0.9，从而更优先地节省带宽。因此，Tambur-0.9 比 Tambur 更优先考虑降低带宽开销。(5) Tambur-low-BW，Tambur 的一个变体，使用 Block-Within 带宽开销的 50%。(6) Oracle，在 Tambur-full-BW、Tambur-low-BW 或 Block-Within 之间进行最优选择。每次发送方从接收方获得反馈时，Oracle 会在能够恢复最多帧的方案中选择带宽开销最小的方案。这种选择永远不会导致不可恢复的丢包。因此，Oracle 恢复的帧数总是至少与 Block-Within、Tambur 和 Tambur-full-BW 一样多。Block-Within 和 Block-Multi 的带宽开销从未降低，以确保对 Tambur 的丢包恢复能力进行公平比较，并且因为尽管两个基线使用了全部带宽开销，其性能已经比 Tambur 差。与 Tambur 类似，Block-Within 和 Block-Multi 在 FEC 解码失败后也会向发送方发送反馈，以触发新的关键帧作为处理帧间依赖的备用机制。

指标。 我们评估以下指标：(1) 不可恢复帧百分比，即未能恢复的压缩帧的百分比。(2) FEC 的带宽开销。(3) 未渲染帧百分比，即未被接收方播放的帧的百分比——这包括未恢复的帧以及依赖于未恢复帧的那些已恢复帧。(4) 延迟，即帧从创建到渲染之间的持续时间。(5) 卡顿频率，即接收方视频卡顿的次数。(6) 卡顿持续时间，即接收方视频卡顿的累计时长。我们仅对应用了 FEC 的帧（即 FEC 影响质量的帧）计算这些指标。我们为每次通话计算一个值（例如，卡顿持续时间的中位数、带宽开销等），然后考虑这些值的百分位数。对于延迟，我们考虑所有通话中的所有帧。

使用所谓的“QoE 模型”[68] 来精确测量 QoE 很困难，因为它依赖于视频特定的属性（例如，在体育节目中，比赛进行时的视频质量比暂停时更重要）。但是，一些工作 [7,21,37] 已经表明，QoE 的关键指标（例如卡顿频率、卡顿持续时间、带宽等）会影响平均意见得分——衡量 QoE 的黄金标准。这些指标也会影响用户交互（例如，卡顿越少，用户观看的视频越多）。事实上，[19] 表明，累计卡顿持续时间对 QoE 至关重要，比特率和视频卡顿频率对直播视频也很重要。

离线评估。 我们在 §3 中描述的来自 Teams 的测试集轨迹上评估了 Block-Within、Tambur、Tambur-full-BW、Tambur-0.9、Tambur-low-BW 和 Oracle 的性能，该测试集在之前的分析中被保留下来。数据包日志提供了 Block-Within 的性能。为了在轨迹上评估其余方案，我们做了两个安全假设：(a) 修改数据包的负载（但不修改其大小）不会改变它是丢失还是被接收；(b) 减小数据包负载的大小不会引起任何新的数据包丢失。每个数据包的发送方式与轨迹中完全相同，奇偶校验包的负载被改变，奇偶校验包的大小有时被减小，并使用轨迹中的数据包丢失位图。为了满足这些假设，我们必须强制 Tambur 在帧内发送为该帧分配的奇偶校验符号数量（而不是延迟 τ 帧发送），我们预计这会降低 Tambur 的性能。这种强制改变了 Tambur 发送的奇偶校验包数量，但没有改变其符号的定义方式。Block-Multi 被排除，因为它将所有奇偶校验包放在块中最后一帧的最后一个数据包之后发送，因此无法使用生产轨迹公平地模拟其性能。

在线评估。 我们将 Block-Within、Block-Multi、Tambur、Tambur-full-BW 和 Tambur-0.9 的原型实现与 Ringmaster（§4.3 中描述的视频会议基准测试平台）集成，通过使用 Mahimahi [46] 进行网络仿真，在 80 个视频的数据集上模拟 Gilbert-Elliott (GE) [23] 丢包模型。具体来说，我们评估了来自 [16,47] 的 20 个视频通话，每个视频有四个恒定比特率（即 500、1000、1500 和 2000 kbps），以隔离 FEC 的影响。Block-Within 的带宽开销设为 50%（Block-Multi 和 Tambur-full-BW 同样设为 50%）。GE 丢包模型是一个标准的丢包模型，它是一个具有两个状态的马尔可夫模型：“好”状态和“坏”状态，每个状态都有相应的丢包概率。为了进行公平和现实的比较，不同的编码方案即使在每帧发送不同数量的数据包，也必须在帧级别经历相同的突发丢包分布。因此，我们考虑状态之间的转换在每帧开始时发生一次（即每 33.3 毫秒一次），而不是像文献中常见的每发送一个数据包就转换一次（那种情况通常假设每帧只发送一个数据包）。每帧内的数据包独立地以相同概率丢失。修改后的 GE 信道可以看作是短期的缓冲区溢出，这种溢出可能由流量的开关特性引起 [49]。附录 C 详细说明了我们如何根据轨迹中的丢包来设置 GE 模型的参数。

结果亮点。

图 10： 离线评估中，第 55 至第 95 百分位数范围内不可恢复帧百分比的累积分布函数（CDF）以及带宽开销。

• 在离线评估中，Tambur 将不可恢复帧的频率降低了 26.5%，同时使用的带宽开销减少了 35.1%。

• 在在线评估中，与 Block-Multi 相比，Tambur 将未渲染帧频率、卡顿频率和卡顿持续时间分别降低了 28%、26% 和 29%；与 Block-Within 相比，分别降低了 73%、78% 和 77%。Block-Multi 的延迟显著高于 Block-Within（见图 13b）。

• 内存开销适中，中位数编码时间和解码时间分别为 575 KB、1.7 毫秒和 3.4 毫秒。

5.2 离线评估

由于离线轨迹中无法获得其余指标，我们仅评估不可恢复帧的频率和带宽开销。图 10a 展示了轨迹中第 55 至第 95 百分位数范围内不可恢复帧百分比的累积分布函数（CDF）。这些百分位数大致对应于所有轨迹中的第 92 至第 99 百分位数。与 Block-Within 相比，Oracle 将不可恢复帧的总数减少了 44.2%，体现了性能的上界。Tambur-full-BW 与 Block-Within 相比，将不可恢复帧的频率降低了 33%，这表明使用流编码具有潜在的改进空间。相比之下，Tambur-low-BW 与 Block-Within 相比，不可恢复帧的频率增加了 34.7%，这表明需要更精细的方法来降低带宽开销，同时避免在不可恢复帧上造成显著损失。通过使用预测模型来确定带宽开销，Tambur 在将带宽开销降低 35% 的同时，与 Block-Within 相比，不可恢复帧的数量减少了 26.5%（图 10b）。§5.3 总结了 Tambur 在调整相关权重参数后，在节省带宽与恢复帧之间的权衡谱系。

图 11： 预测模型中用于不可恢复帧频率和带宽开销的类别权重的敏感性分析，基于轨迹中使用 FEC 的所有帧。

5.3 敏感性分析

在不可恢复帧和带宽开销这两个指标的性能之间存在固有的权衡。Tambur 的 ML 模型在训练时使用的损失函数中，避免恢复失败的权重为 0.999，节省带宽开销的权重为 0.001（§4.3）。图 11 展示了该参数对 Tambur 帧恢复性能的影响，其中权重分别设为 0.9（即 Tambur-0.9）和 0.5。这两种方案在不可恢复帧上的改善分别为 21.9% 和 1.7%，在带宽开销上的降低分别为 40.3% 和 45.2%。相比之下，回顾一下 Tambur 在不可恢复帧上实现了 26.5% 的改善，同时带宽开销降低了 35.1%。降低该参数的值会降低帧恢复的频率，并增加带宽开销的降低幅度。视频会议服务运营商可以将这些权重用作调节旋钮，以优先考虑某一指标而非另一指标。

5.4 在线评估

接下来，我们验证 Tambur 改善 QoE 的潜力。为了便于与离线评估进行比较，我们在图 12 中展示了不可恢复丢包的频率和带宽开销（同 §5.2）。平均而言，与 Block-Within 相比，Tambur 将不可恢复帧的数量减少了 69%；与 Block-Multi 相比，减少了 34%。尽管 Block-Multi 的延迟要高得多（图 13b），但 Tambur-0.9 与 Block-Within 相比将不可恢复帧数量减少了 65%，与 Block-Multi 相比减少了 26%。由于我们根据所有轨迹的平均丢包统计信息设置了信道参数，因此低百分位数上的结果与离线评估略有不同。这显著降低了低丢包率通话的频率，在低丢包率下，任何编码方案都足以恢复几乎所有帧（即不需要复杂的 FEC 方案）。

                  图 12： 在线评估中不可恢复帧百分比和带宽开销的累积分布函数（CDF）。

Tambur 在冒着恢复失败风险以节省带宽方面较为保守，平均将通话的带宽开销降低了 3%。相比之下，Tambur-0.9 平均将带宽开销降低了 8% 以上。这些结果反映出两种方案在某些通话上显著降低了带宽开销，但在许多其他通话上降低幅度很小，考虑到大多数通话的丢包率，这是意料之中的。Tambur-0.9 的带宽节省在较低百分位数上尤为显著（例如，在第 10 百分位数节省 31%，在第 20 百分位数节省 15%）。尽管在线评估反映的是其神经网络（基于生产轨迹离线训练）的样本外性能，Tambur-0.9 仍然同时实现了恢复更多帧和节省带宽的双赢。这些结果进一步验证了 §5.3 中讨论的带宽开销与帧恢复之间的权衡关系。

接下来，我们考察图 13a 中未渲染帧的百分比；需要回顾的是，由于帧间依赖关系，渲染的帧数少于恢复的帧数。与 Block-Multi 和 Block-Within 相比，Tambur 平均将未能渲染帧的频率分别降低了 28% 和 73%。在尾部，Tambur 的表现比 Block-Multi 差，但这仅发生在所有方案的失败率均高于 23% 之后。因此，所有方案都应采用更多的冗余。与 Block-Within 和 Block-Multi 相比，Tambur-0.9 平均将未能渲染帧的频率分别降低了 70% 和 20%。在第 75 百分位数，与 Block-Multi 相比，Tambur-0.9 的该频率略微增加了 1%。总体而言，对于大多数通话，可以在降低带宽开销的同时提高帧渲染率。这些结果是首个证明在存在帧间依赖时流编码优势的工作。

图 13： Tambur 渲染的帧数显著多于 Block-Multi，且延迟更低。Tambur 比 Block-Within 略高的延迟完全被其在帧渲染方面的改进所抵消。

图 13b 显示，所有方案的端到端延迟都在约 150 毫秒的上限之内。Block-Within 的延迟略低，因为其编码/解码时间更短，并且始终使用同一帧的奇偶校验来恢复渲染帧（参见附录 D 的图 15 和图 16）；Tambur 有 87% 的帧无需额外帧即可解码，而 Block-Within 的这一比例为 88%，因此等待额外帧带来的额外延迟实际上应该与 Block-Within 完全解码失败的情况进行比较。我们认为，考虑到在其他 QoE 指标上的显著改善，Tambur 较小的代价（例如，中位数编码时间多 1.7 毫秒，解码时间多 3.4 毫秒）是值得的。我们也注意到，我们实现的 Tambur 流编码尚未针对快速编码/解码进行优化；因此，我们相信它可以显著加快。我们的目标是证明 Tambur 的流编码对于视频会议应用而言足够实用。

图 14： Tambur 的卡顿持续时间中位数高于 Block-Within，但其卡顿累计持续时间显著低于 Block-Within，因为 Tambur 的卡顿次数比 Block-Within 少 78%（图 1）。与 Block-Multi 相比，Tambur 的卡顿累计持续时间和中位数持续时间均更低。

回顾图 1，与 Block-Within 和 Block-Multi 相比，Tambur 分别将卡顿频率降低了 78% 和 26%；与这两个基线相比，Tambur-0.9 分别将卡顿频率降低了 75% 和 17%。图 14a 显示，与 Block-Multi 相比，Tambur 和 Tambur-0.9 各自将卡顿持续时间的中位数平均降低了 30 毫秒。Tambur 和 Tambur-0.9 的卡顿持续时间中位数比 Block-Within 长 90 毫秒，因为 Block-Within 的卡顿次数比 Tambur 多 300% 以上。多出的许多卡顿持续时间很短，从而将 Block-Within 的中位数拉低到 Tambur 之下。与 Block-Within 相比，Tambur-0.9 将卡顿累计持续时间平均降低了 69%。尽管 Tambur-0.9 的卡顿持续时间中位数平均短 11%，卡顿次数少 17%，但 Block-Multi 的卡顿累计持续时间比 Tambur-0.9 低 17%。虽然 Block-Multi 和 Tambur-0.9 在卡顿频率和持续时间对 QoE 的综合影响上相似，但需要回顾的是，Tambur-0.9 还改善了带宽开销，并为大多数轨迹渲染了更多帧。因此，我们预计 Tambur-0.9 将提供整体更高的 QoE。与 Block-Within 和 Block-Multi 相比，Tambur 的卡顿累计持续时间平均分别短 77% 和 28%，这是一个明确的胜利。在尾部，Tambur、Tambur-0.9 和 Tambur-full-BW 的卡顿累计持续时间高于 Block-Multi。我们认为这不太重要，因为尾部的 QoE 已经很差，表明所有方案都需要更多的带宽开销。附录 E 解释了这一现象是实现中的人工产物，并包含我们提出的解决方案。

Tambur、Tambur-full-BW 和 Tambur-0.9 在多个 QoE 指标上的优势表明，与 Block-Within 和 Block-Multi 相比，其 QoE 得到了显著改善。在不使用机器学习来降低带宽开销的情况下，Tambur-full-BW 相较于两个基线提供了实质性的改进。Tambur 和 Tambur-0.9 则在丢包恢复的改进与带宽开销之间逐步进行权衡。总体而言，这些结果展示了流编码在 QoE 指标上的帕累托前沿，这可以在未来的工作中进一步研究。

6 相关工作

用于视频会议的 FEC。 从 VoIP 和基于互联网的音频/视频会议的早期开始，FEC 就在恢复丢失的数据包方面发挥了关键作用（例如 [50]）。随着实时媒体和会议标准的发展，针对各种 FEC 方案的 RTP 载荷格式被定义（例如 [62]）。后来，IETF 的 FECFRAME 工作组 [58] 记录了传统的 FEC 方案，如奇偶校验码 [9]、RS 码 [57]，以及 LDPC 码 [56] 和 Raptor 码 [65]。随着 WebRTC 项目基于这些标准发展，它也整合了使用 FEC 来保护媒体流 [32, 64]。所有这些编码都是分组码。因此，RS 码（即评估 Tambur 时使用的主要基线）具有其中最好的丢包恢复能力，包括喷泉码 [40] 和 Raptor 码 [63]。FEC 也被用于速率适配。例如，一个为 WebRTC 提出的速率适配算法 FBRA [45] 使用额外的 FEC 数据包来探测额外带宽，其好处是，由于自身引起的拥塞导致的部分丢包可以被 FEC 恢复。

流编码。 除了 §2 和 §4 中讨论的先前工作外，流编码还在其他各种理论模型下进行了研究，例如具有两种不同解码延迟的复用 [4] 和多次突发丢包 [38]。然而，这些设置与我们关注视频会议应用不直接相关。

FEC 的替代方案。 先前的工作探索了使用 overlay 网络来避免有损路径（例如 Via [34] 和 J-QoS [31]）。虽然这些方法在某些情况下有效，但仅依赖这类方法有两个缺点。首先，这些方法假设存在合适的替代路径（即，路径中的有损部分位于可避免的传输网络上，而不是用户家庭网络或到 ISP 的最后一公里，并且存在与提供商 overlay 网络的可用互联）；在当今混合办公的时代，企业无法通过传统的 QoS 方法完全消除丢包。其次，当 overlay 网络是可行的解决方案时，需要仔细分析何时应用该方法，因为中继流量和提供商网络上的固定容量具有很高的财务成本。FEC 的另一个替代方案是使用重传来恢复丢包（例如 [30]），前提是端到端延迟是可容忍的。但是，当同时存在高延迟和丢包时（例如在严重拥塞的情况下），重传并不总是可行的 [3]。Tambur 在应用内部提供了一种灵活的端到端解决方案，能够适应任何网络路径，并且与这些其他方法是正交的。

7 结论

本文介绍了 Tambur——一种用于视频会议中带宽高效丢包恢复的新型通信方案，它包含两个组成部分。第一，一种新的流编码，它弥合了理论流编码与视频会议应用之间的差距，能够以任意给定的带宽开销作为输入。第二，一个基于学习的预测模型，用于设置带宽开销。在我们对来自商业视频会议应用的大规模真实轨迹进行的评估中，Tambur 同时将不可恢复帧的频率和带宽开销分别降低了 26.5% 和 35.1%。我们还设计了首个用于实现和评估 FEC 方案的视频会议框架。该框架通过提供一个简单的接口来集成 (a) 新的 FEC 方案和 (b) 新的基于学习的预测模型，从而能够轻松评估新通信方案的 QoE 收益。使用该框架，我们评估了 Tambur，并展示了其在 QoE 指标上的改进，包括卡顿减少 26%，未渲染帧减少 28%。这些优势确立了流编码作为视频会议应用中恢复丢包的一种可行解决方案。因此，这些结果也显示了流编码对于其他直播应用（如云游戏）的前景。

附录

A 使用 Tambur 流编码恢复突发丢包

考虑一个从帧 i 开始、长度为 b、延迟约束为 τ 的突发丢包。假设突发之前的所有帧都已被解码。首先，使用接收到的 P[i]、...、P[i+b-1] 以及 P[i+b]、...、P[i+τ] 的符号来解码 V[i]、...、V[i+b-1] 中丢失的符号。其次，对于 j ∈ {i, ..., i+b} 中的每个 U[j]，使用 P[j+τ] 进行解码。在这两个步骤中，解码都通过求解线性方程组来完成。

B Tambur 流编码的流网络图

从高层来看，流网络图表示每个可能用于解码的 P[i] 为一个节点，该节点具有指向对应 U[i]、U[i-τ]、V[i]、...、V[i-τ] 的节点的边，其中一单位的流代表解码一个符号。该流网络很小（例如，当 τ = 3 时，最多有 (5τ+3) 个顶点和 (2τ² + 11τ + 5) 条边）。因此，与求解线性方程组的时间相比，求解该流网络的时间可以忽略不计。

C GE 信道的参数

为了设置离线评估中 GE 信道的参数，我们首先按照以下方式确定与生产轨迹的几个聚合统计量相匹配的设置。从坏状态到好状态（反之亦然）的转移概率是轨迹上以帧为单位的突发（或保护间隔）平均长度的倒数之均值。坏状态下的丢包概率等于轨迹上多帧突发性的均值。然后设置好状态下的丢包概率，使得在给定其他三个参数的情况下，预期丢包率与轨迹上的平均丢包率相匹配。为了确保我们的结果适用于不同的网络条件，我们随后从这些值周围的区间内均匀随机抽取四个参数的值（四舍五入到 0.05 的增量），具体如下：从好状态到坏状态和从坏状态到好状态的转移概率分别服从 Uniform(0, 0.05) 和 Uniform(0.75, 0.9) 分布。好状态和坏状态下的丢包概率分别服从 Uniform(0, 0.05) 和 Uniform(0.05, 1) 分布。

图 15：编码和解码时间适中。

D 编码和解码开销

我们比较了 Tambur 与 Block-Within（所有基线中最快的）的编码和解码时间（图 15）。如图 15 所示，编码和解码时间与 Block-Within 相当，并且仅占 150 毫秒端到端延迟预算的一小部分。Tambur 和 Block-Within 的编码时间中位数分别为 1.7 毫秒和 0.6 毫秒，而解码时间中位数分别为 3.4 毫秒和 0.7 毫秒。由于 Tambur 在多个大小不同的帧上操作，其编码和解码时间稍长且变化更大。我们实现的 Tambur 在编码和解码期间需要约 575 KB 的固定内存量。

但编码和解码时间只是端到端延迟的一小部分。50 毫秒的单向延迟和解码中使用的额外帧数量（见图 16）具有更显著的影响。需要回顾的是，每增加一个额外帧，端到端延迟大约增加 33 毫秒，因此使用更少的额外帧速度更快。Tambur 仅在相同帧内解码的频率仅比 Block-Within 高 1%，而 Block-Within 无法在解码中使用额外帧。Tambur 仅有 8% 的时间使用额外帧进行解码。Block-Multi 使用 0、1、2 和 3 个额外帧解码的帧比例分别为 24%、23%、23% 和 23%。每个额外帧给端到端延迟增加约 33 毫秒。

图 16： Tambur 在不使用额外帧的情况下恢复的帧数几乎与 Block-Within 一样多，并且总体上恢复了更多的帧。Block-Multi 使用 0、1、2 和 3 个额外帧恢复的帧数大致相等。

E 尾部卡顿持续时间

回顾图 14b，Tambur、Tambur-0.9 和 Tambur-full-BW 的尾部卡顿持续时间高于 Block-Multi。性能不佳的原因有三。首先，正如 §5.2 所讨论的，Tambur、Tambur-0.9 和 Tambur-full-BW 在尾部未能渲染更多帧。其次，发送方一旦得知恢复失败就会生成一个关键帧（通常结束卡顿）。由于 Block-Within 只能使用同一帧内的奇偶校验包来恢复帧，因此它比使用 Tambur（或 Tambur-0.9）时提前 3 帧（即快约 100 毫秒）请求关键帧。因此，在 Block-Within 下 78% 的卡顿（而 Tambur 没有卡顿）中，许多卡顿持续时间很短，并且改变了 Block-Within 的整个卡顿累计持续时间分布，包括尾部；如果我们为 Tambur（或 Tambur-0.9）在这些实例中加上 0 毫秒的卡顿，它们的分布也会同样改变。第三，跨多个帧编码可能使得恢复由多个丢失帧触发的关键帧更加困难。这种现象不影响 Block-Within，并且对 Block-Multi 的影响小于对 Tambur、Tambur-0.9 和 Tambur-full-BW 中的任何一个（例如，只要关键帧位于 (τ+1)=4 帧块中的第一个位置，就不会影响 Block-Multi）。这种现象也导致了恢复帧频率（图 12a）和渲染帧频率（图 13a）之间的差异。有一个自然解决方案，但超出本工作范围：当发送方因丢包触发新的关键帧时，它应停止对来自新关键帧之前的帧进行线性组合。这样做将严格地 (a) 提高帧显示的频率，并 (b) 减少卡顿的平均和中位数持续时间。这对 Tambur、Tambur-0.9 和 Tambur-full-BW 最有利，但也会在一定程度上改善 Block-Multi。

F 突发恢复能力分析

图 17： 在与 Block-Within 相同的带宽预算下，对于生产环境轨迹中的突发丢包，Tambur 更倾向于要么恢复全部帧，要么一个都不恢复。

图 18： 在与 Block-Within/Block-Multi 相同的带宽预算下，对于模拟网络中较长的突发丢包，Tambur 提供了更大的改进。

接下来，我们评估 Tambur 恢复跨多个帧的数据包突发的能力；为了公平评估，我们必须固定带宽开销，因此在 §F 的其余部分中，“Tambur”指的是 Tambur-full-BW。图 17 显示了离线评估中，针对每种突发长度（以帧为单位）恢复的数据包数量的分布。在图 17 中，展示了每种突发长度（以帧为单位）恢复的数据包数量的分布。涵盖 2、3 和 4 帧的突发分别占所有丢包事件的 23%、7% 和 3.3%。对于这些丢包，Tambur 恢复所有丢失帧的频率分别比 Block-Within 高 66.8%、103% 和 97.3%。对于较长（较不频繁）的长度为 3 和 4 的突发，当带宽开销不足时，Tambur 未能恢复任何帧的频率分别比 Block-Within 高 65.9% 和 87%。这是因为当带宽开销不足以恢复所有丢包时，Block-Within 更有可能恢复部分（但不是全部）帧。相比之下，当带宽开销不足以完全恢复一个突发时，流编码可能会无法恢复所有帧。然而，请注意 Tambur 的整体性能仍然优于 Block-Within：对于 2、3 和 4 帧的突发，Tambur 恢复的帧数分别比 Block-Within 多 21.8%、12.4% 和 2.3%。Tambur 在恢复仅限于单帧的丢包方面也优于 Block-Within，因为后续帧发送的奇偶校验包可用于恢复。简而言之，对于最多 3 帧的突发，Tambur 的性能显著优于 Block-Within，而对于 4 帧的突发，Tambur 带来的增益较为温和。

我们还在在线评估中评估了 Tambur 恢复突发的有效性。由于根据我们对突发的定义，帧的一个数据包丢失即意味着该帧“丢失”，因此较长的突发通常只涉及处于坏状态一帧、两帧或有时三帧。我们考察了图 18 中涵盖 1、2、3、4 或大于 4 帧的突发中平均恢复的帧数。对于 2、3 和 4 帧的突发，与 Block-Within 相比，Tambur 将不可恢复帧的频率分别降低了 70.5%、68.0% 和 65.8%。对于 2、3 和 4 帧的突发，与 Block-Multi 相比，Tambur 将不可恢复帧的频率分别降低了 35.8%、40.3% 和 47.4%。

源码:

https://github.com/Thesys-lab/tambur

https://github.com/microsoft/ringmaster