跳帧技术实现高帧率 UHD 实时通信 (RTC)

超高清晰度实时通信(UHD)用户在高帧率和高比特率的情况下，有时会出现严重的服务退化问题。由于在客户端传入和解码帧时的波动，在客户端流解码器之前可以形成一个解码器队列。这些波动很容易使解码器队列超载，并对这些队列帧引入明显的延迟。本文提出了一种帧跳跃机制，通过主动管理解码器队列中的帧，有效地降低了队列延迟。在保证视频编码解码质量的同时，我们对帧进行跳频优化，以保持端到端的时延。我们还用马尔可夫链数学地量化了潜在的性能。我们基于网络 trace 在 UHD RTC 的仿真环境下的评估帧跳跃机制的性能。实验结果表明，跳帧可以使解码器严重队列延迟比率降低 23 倍，使较为严重的总体延迟比率降低 2.6 倍。

来源：HotEdgeVideo’21
作者：Tingfeng Wang 等
论文题目：Enabling High Frame-rate UHD Real-time Communication with Frame-Skipping
论文链接：https://dl.acm.org/doi/pdf/10.1145/3477083.3481582
内容整理：尹文沛——煤矿工厂

简介

随着 2019 大流行对高清晰度及互动式视频流媒体的需求日益增加，超高清(UHD) 实时通讯 (RTC) 流媒体所共享的网络容量显著增加。这些 UHD RTC 服务，如 UHD 远程会议，虚拟现实和云游戏，现在吸引了学术界和工业界的注意。为了满足用户的需求，UHD RTC 服务的目标是提供高比特率(高达30mbps)和高帧速率(高达60fps)的流媒体服务，同时提供超低的交互延迟帧率。

现有的流媒体传输流水线可以满足传统的流媒体服务，如 4k 视频流。然而，在高帧速 UHD RTC 业务下，这种传输管道可能是次优的。例如，由于网络抖动和解码时间的变化，客户端的流式解码器可能无法及时解码视频帧。在这种情况下，当新帧在解码前到达时，新帧必须在解码前排队。这种解码队列的形式可能会对排队帧引入较高的队列延迟。高帧频以及网络抖动将导致视频帧的突发传入，从而使队列瞬间超载。而高比特率意味着视频帧更加复杂，这可能会增加解码时间。这些原因将导致解码器队列的排队延迟数十毫秒，甚至更长。随着来自应用程序的实时通信需求的增加(例如，在虚拟现实应用程序中不到 20 毫秒) ，这种巨大的解码器队列延迟变得显而易见，需要消除。

然而，由于以下原因，管理解码器队列以实现低延迟和高图像质量是非常重要的。简单的解决方案包括控制解码器队列的到达速率(即帧速率)或服务速率(即解码时间)。然而，由于编码器和解码器位于距离较远的地方，由于控制回路(包括中间网络延迟，编码器的有效延迟)的影响，动态改变编码参数是一个挑战。因此，动态调整帧速率(以降低帧的到达率)或比特率(以加快帧的解码时间)是不够及时的。

因此，在主动队列管理(AQM)研究的激励下，我们不再控制到达率或服务率，而是直接控制解码器队列中的帧：当解码器队列建立完成后，直接丢弃队列中的帧可以有效地减少剩余帧的排队延迟。然而，简单的丢弃队列中的帧将使后续的帧无法解码，并进一步降低由于相互依赖的图像质量。因此，我们需要联合优化帧，以保持较低的解码器队列延迟，并通过重新排序编码器缓冲区来保证解码质量。

本文提出了帧跳跃机制，在不损害解码质量的前提下，对编码器缓冲区进行重新排序，并在解码队列中小心地跳过帧。此外，FrameSkipping 通过控制跳过率来控制延迟改进和帧丢失性能，这表明有多少帧将被跳过。为了将这种全新的解码器队列管理方法应用于 UHD RTC 业务，将引入一个数学模型来量化不同跳跃率下的性能。并给出了基于该模型的数值算例，以推荐跳帧率。

我们评估的帧跳跃机制，在模拟器中使用真实的从云游戏服务中获取的 UHD RTC 跟踪 60 亿视频帧产生的 trace 进行评估。仿真结果表明，跳帧可以使解码器严重队列延迟降低 23 倍，使严重总延迟的帧比降低 2.6 倍。此外，跳帧只会造成图像质量的轻微损失，不会给解码器和网络传输带来额外的压力。

背景和动机

在这一部分，我们阐述了解码器队列过载的场景，并介绍了现有的消除队列过载的解决方案，以帮助我们设计帧跳跃。

解码队列过载

由于 UHD RTC 业务的帧速率和比特率较高，需要传输和解码的视频帧和视频数据较多，从而提高了解码队列的利用率。随着更多的波动，由于流在互联网上，一个巨大的解码器队列延迟可能会发生，并降低用户的体验。

我们研究了基于 60 亿帧规模的网络轨迹，评估解码器队列延迟的严重性。我们首先注意到解码器队列延迟问题会随着平均解码时间的延长而变得更加严重。根据图 1，我们注意到对于那些平均解码时间 ≥12ms 的流到客户端的帧，解码队列延迟 > 50ms 的帧的比率将超过 1% 。也就是说，在 60fps 的视频流中，平均每两秒（2s 120帧，百分之一概率就是1帧延迟 > 50ms）发生一次。与 RTT 和解码时间的十几毫秒延迟相比，这种严重的解码器队列延迟(> 50ms)是显着的，并且可能容易导致一个显著的总延迟降低用户的体验。因此，有必要消除严重的解码器队列延迟。

图1 按平均解码时间分组的帧的解码器队列延迟 > 50ms (蓝线)和解码器队列延迟第 99 百分位(红线)的比值。

根据队列理论，队列超载只有在到达率较高或服务率较低(解码速度)或两者兼而有之的情况下才会发生。到达率，即从网络传入的帧的速度，受到网络环境的影响。服务速率将表示为 UHD RTC 服务一段时间内的平均解码时间。如果平均解码时间较长，那么在一段时间内解码时间较长(服务速率较低)的可能性就更大，因此更容易遇到队列超载。因此，对于平均解码时间较长的客户端来说，该方法更有价值。

队列过载的可能解决办法

为了保持较低的队列延迟，我们将讨论一些可能的解决方案。

到达率管理
保持低队列延迟的一个解决方案是通过改变队列到达端的到达率来避免队列积累。

由于到达率和服务率的变化也会导致队列开销，因此在网络抖动和解码时间变化下，预协商较低的到达率不能保证持久的低队列延迟。

在 UHD RTC 业务中，当我们试图实时改变到达率时，由编码器决定到达率，而客户端距离较远。因此，由于网络运输的存在，到达率的调整将产生一个较长的控制回路。这个控制回路可以看作是服务的往返时间(RTT)。根据 UHD RTC 服务的类型，被认为是 RTT 的控制回路可以从10ms (像云游戏这样的边缘加速流服务)到50ms + (UHD 远程会议)。

我们的实际 trace 表明，即使在到达率调整的即时反应下，解码器队列仍然可能超载。在图2(a)中，我们假设到达率管理可以立即作出反应，即，我们可以预测将有一个严重的队列延迟(解码器队列延迟 > 50ms)后，第一帧开始排队。我们将发送一个到达率改变命令，在一个 RTT 控制循环后，新的到达率将会被激活。网络 trace 中 RTT 的中位数为 15ms (图2(a)中的中间线) ，已经有三个平均排队的帧。它说明了解码器队列在大量帧到达时会超载。而到达率管理由于其固有的长控制回路而受到限制。

图2 严重队列延迟(解码器队列延迟 > 50ms)的第一个队列延迟后的传入帧和相应的解码时间。

此外，如果我们试图使用一些预测方法来预测突然袭来的反应（大量帧到达），仍然会有一些局限性。首先，到达率调整的输出动作是基于实时变量测量的。测量延迟产生输出动作，再加上十几毫秒的长控制回路仍然可能导致帧排队发生在到达率激活之前。其次，试图在突发事件发生之前预测突发事件将面临错误预测问题，而最小化预测错误仍然具有挑战性。

此外，等待那些突发传入帧排队的时间是显而易见的。根据图2(b) ，这三个 15ms RTT 以下的突发传入帧平均需要花费 34ms 去排队(解码)。因此，随后传入的帧可能会遭受几十毫秒的排队延迟。在 RTT 为 32ms (图2(b)中的右行) 的第90百分位数下，这个问题甚至会更糟。

加速解码时间

保持低队列延迟的另一个解决方案是加快服务速率(解码时间)。但是解码时间代表了帧复杂度，简单地通过降低帧复杂度来提高解码时间会降低图像质量。对于未经授权修改系统过程(如 CPU 调度)的应用程序来说，尝试提高编解码器模型中的执行时间是具有挑战性的。为了快速有效地消除解码队列延迟，我们提出了跳帧机制来实现所有这些目标。

设计

在这一节中，我们首先介绍了帧跳跃机制，然后用马尔可夫模型对该机制进行了理论分析。

跳帧机制

为了介绍帧跳过机制，我们首先简要介绍了在解码器队列中丢弃帧的功能，并回答了我们设计中的两个关键问题，即跳过哪些帧和跳过多少帧。

背景：重新排序解码器缓冲区。视频编解码标准的帧间预测是在前帧预测的基础上对视频帧进行编码和解码。现在随着可适性视讯编码(SVC)的发展，流媒体中的一些帧现在可以丢弃了。因此，我们可以利用 SVC 扩展或 NVIDIA video codec InvalidateRefFrames API 来重新排序编码器参考帧序列，从图3(a)到图3(b)。

在对编码器参考帧序列重新排序后，为了保证丢弃后的解码质量，有些帧不能用来预测后续帧。因此，当我们提取解码器队列中相邻帧的图片组(GoP)容量时，必须有一个基层帧(图3(b)中的黑帧0、2等)。由于基本层帧是唯一用于预测下列 GoP 帧的帧，因此仅对基本层帧进行解码并在 GoP 中丢弃其他帧不会损害解码质量。

跳过哪些帧？在具有丢弃解码器队列中帧的能力后，我们提出了主动队列管理(AQM)——跳帧算法，以有效地消除解码器队列延迟。

在 Frame-Skipping，我们会选择在排队时丢弃较早的帧，而不是像广泛使用的尾部丢弃 AQM (RED，PIE，等等)那样在排队时丢弃最新的到达帧。这是因为我们的目标是保持较低的队列延迟，而不仅仅是较低的队列长度，丢弃较早的帧，和渲染最新的帧可以提供较低的延迟流。

更具体地说，当解码器队列超载时，我们将在解码器队列的头部提取相邻帧的 GoP 量，然后只解码一个并跳过(删除)其他相邻帧。直观地说，同时提取更多帧意味着更有效地消除解码器队列延迟，但也意味着更多帧将被丢弃(更多的网络带宽浪费)。他们之间会有一个平衡。

最后，本文提出了一种基于跳帧的主动队列调度算法来有效地消除解码器队列延迟。我们选择在出队时丢弃帧以提供较低的延迟流，并提供一个参数跳过率 q 来平衡延迟改进和帧丢失之间的权衡。

为了量化 Frame-Skipping 不同跳转率 q 的延迟改进和帧损耗性能，我们引入了一个数学模型，并用数值例证如下。

理论分析

数值例子

为了量化性能并提供一些推荐的跳帧率 q，我们将提供一个数值说明。我们设定60个帧率的到达率，即 lambda = 60，并设定解码器时间 = 12ms 的服务率(在图1中有明显的解码器队列延迟) ，即服务率 μ = (0/0.012) ≈ 80。

我们评估了跳帧率 q，q ∈ [0,0.5] 下的延迟改进和帧丢失性能。根据图 5，随着跳帧率的增加，队列长度的期望值和尾部延迟比例(队列长度≥4)减小。然而，当跳帧率增加时，帧丢失状态变得更糟。因此，在延迟改进和帧损失之间存在权衡。

对于在这种权衡下选择的跳帧率，我们实验和。当时，队列长度期望值降低到 1，尾延迟比降低到，帧丢失率不超过。当时，我们可以获得显著的延迟改进，这对于像云游戏这样对延迟敏感的 RTC 服务是很有吸引力的。跳帧率的进一步研究将以用户的体验作为我们今后的工作。

评估

在这一部分中，我们通过在帧级 trace 驱动的 RTC 模拟器中实现跳帧机制来评估它的性能，并研究在部署跳帧机制时可能遇到的一些障碍。

延迟性能提升

为了比较不同解码器队列管理的延迟改进，我们设计了一个模拟器，它可以在客户端忠实地实现在线的网络 trace，并对解码器队列调整作出反应。

仿真设置

基线：为了评估跳过框架的延迟改进，我们还评估了以下基线:

默认设置。我们的在线 trace 服务中的默认队列管理类似于 WebRTC。当解码器队列大小超过设置的阈值时，客户端将请求一个新的密钥帧并尝试刷新解码器队列。
Pause-encoder: 暂停编码器工作，直到解码器队列长度低于设置的阈值。在这种管理下，我们将设置解码器队列长度阈值，分别为(pause1)和(pause2)。因此，如果队列长度超过设置的阈值，我们将发送一个暂停命令，直到队列长度低于阈值。

网络轨迹：为了研究长解码时间客户端的跳帧性能，仿真将所有流跟踪和弱解码跟踪(平均解码时间≥12ms 的跟踪)分开运行。

指标：我们评估跳帧性能与延迟改进和帧丢失。较低的延迟意味着 RTC 具有更好的交互性，而且，解码器队列延迟和总延迟(从用户输入到图形显示)将表现出较好的延迟改善性能。

跳帧会造成帧丢失，影响网络的平滑性和网络资源的利用率。然而，我们不打算深入研究帧速率降低(跳过速率 q = 0.5 下60 ~ 30 fps)将如何影响用户体验，因为即使在游戏场景下，在60 fps 和25 fps 之间也没有发现质量评级和性能评级的显着差异。

评估结果

跳帧的目的是减少延迟，以帮助交互式服务。对于解码器队列延迟，我们给出了第 99 个百分点，解码器队列延迟 > 50ms (严重队列延迟)的帧之比和平均值。在图 6 中，与缺省队列管理相比，跳过率 q = 0.5 的帧跳过算法可以将 99% 分位数的解码器队列延迟从 22ms 压缩到 1ms，并且在弱解码trace 下从 88ms 压缩到13ms。对于严重解码队列延迟(解码队列延迟 > 50ms)的帧比，跳帧可以使所有 trace 的帧比降低23倍，弱解码 trace 的帧比降低53倍。这些结果表明，跳帧可以有效地降低译码器队列延迟。

图6 解码器队列延迟的仿真结果(99%) ，解码器队列延迟大于 50ms 的帧(遭遇严重队列延迟的帧占总帧数的比例)之比，以及平均值(平均队列延迟)

此外，跳帧还可以通过消除解码器队列延迟来降低总延迟。根据图 7，跳过率 q = 0.5 的帧跳过可以在所有 trace 条件下将 99% 总延迟从 89ms 压缩到 62ms，在弱解码 trace 的情况下从 139ms 压缩到 90ms。对于严重的总延迟比(总延迟 > 100ms) ，跳帧可以使所有流 trace 的延迟比降低 2.6 倍，弱解码 trace 的延迟帧比降低 4.4 倍。因此，跳帧可以帮助服务提供商提供更好的 UHD RTC 服务。

图7 总延迟仿真结果( 99%位点，总延迟大于100ms 的帧的比值，平均总延迟)

对于帧丢失的情况，根据图 8，我们可以注意到，更好的延迟改进性能也意味着更多的帧丢失。因为更好的延迟改进是通过暂停/跳过更多帧来实现的。

与暂停编码器基线相比，帧跳过的延迟改进性能仍然优于暂停编码器管理(图6)。结果表明，由于处理突发队列波动的局限性，与跳帧相比，到达率管理中消除解码队列延迟的效率仍然不够好。

对于仿真结果，我们还观察到，所有队列管理可以在弱解码 trace 下有更好的延迟改进性能。随着弱解码 trace 下跳帧技术的显著延迟改进，对于解码时间较长的客户端来说，实现跳帧技术具有更大的应用价值。

微观基准

我们评估了编码器缓冲区重排所编码的帧的一些参数，以研究在部署跳帧时可能遇到的一些障碍。

帧尺寸。根据我们的评估，帧大小差异很小。与默认编码帧相比，只有 2% 的帧具有超过一半的帧尺寸差异。这样就不会给网络传输带来更大的压力。此外，在相同的编码配置下，可能存在较大的帧尺寸差异。

解码时间。在我们的测试中，重新排序编码器缓冲区编码的帧与原始帧之间的平均解码时间几乎相同(解码时间差小于 3%)。所以解码器不会有额外的压力。

图像质量。我们使用 PSNR 来测量图像质量，它被广泛用于图像质量度量。根据我们的评估，重排序编码器缓冲区编码的帧与原始编码帧相比，平均有 0.8 dB PSNR 评分损失的图像质量下降，即图像 PSNR 评分损失 2% 。

讨论

在这一部分，我们将讨论未来的可行性和跳帧的特点。

未来的可行性。帧跳过利用 SVC 扩展或 NVIDIA 编解码器 API 来重新排序编码器缓冲区，以有效地消除解码器队列延迟。因此，我们想知道是否仍然可行的编码器缓冲区重新排序与编解码器标准升级的未来。可适性视讯编码(SVC)扩展现在支持 H.264和 H.265标准，也支持全新的 H.266标准。另一方面，无论将来采用什么样的编解码标准，我们仍然可以利用编码器的 API 直接使编码器缓冲区中最近的图像失效，从而重新排序编码器缓冲区。

高级队列管理。许多研究也关注于通过部署队列管理来改善流服务体验。例如，控制器将改变网络数据包的发送速率，以保持较低的因特网队列延迟。但是解码器队列是在视频帧水平上工作的，一个队列帧在60fps 的流下可能引入16ms 的延迟。因此，与排队的网络数据包相比，它将更加引人注目。

此外，那些关注帧级别的队列管理位于服务器的编码器端。因此，长控制环路将限制解码器队列延迟的消除效率，正如我们前面所讨论的。然而，我们的客户端跳帧机制可以立即有效地消除突发队列波动。

跳帧场景。在本文中，我们利用 SVC 和编码器的 API 在解码前跳过视频帧而不损害图像质量。此外，一些用例还受益于视频丢弃，如视频分析。然而，跳帧和视频分析中丢弃帧的对象是完全不同的。跳帧技术旨在通过消除队列延迟来实现超低延迟的实时通信。另一方面，视频分析正在过滤/丢弃帧，以解决视频流和分析模型的高计算和网络资源需求的挑战。优化对象的差异性使得不同场景下的帧丢弃调度不同。