新兴的高质量实时通信（real-time communication, RTC）应用程序流式传输高帧率（high frame rate, HFR）的超高清（ultra-high-definition, UHD）视频。它们利用边缘计算实现高带宽和低延迟的流媒体传输。在全球最大游戏公司之一的云游戏平台上的测量结果显示，在这种情况下，客户端解码器处的队列通常是导致高延迟，影响用户体验的原因。因此，本文提出了一种自适应帧率（Adaptive Frame Rate, AFR）控制器，通过自适应地协调帧率与波动的网络条件和解码器容量，帮助实现超低延迟。AFR的设计解决了两个关键挑战：（1）队列测量不能为控制循环提供及时反馈；（2）多个因素控制着解码器队列，并且根据队列积累的原因需要采取不同的操作。通过基于轨迹的模拟实验和大规模部署，证明AFR可以将尾部排队延迟降低多达7.4倍，并将由端到端延迟测量的卡顿事件平均降低34%。

1. 背景介绍


5G等新兴网络技术促进了学术界和产业界对超高清、高帧率和低时延的高质量实时通信。为了获得令人满意的用户体验，流媒体等应用程序需要以高分辨率、高帧率和低延迟进行流式传输。本文认为，除了通过调整比特率以匹配网络容量外，高质量的实时通信（RTC）系统还必须调节解码器队列中的排队情况。对于传统标准质量的RTC，解码一帧所需的时间远远小于帧的到达间隔时间。因此，解码器队列不是瓶颈，传统的RTC服务只需要调整比特率以匹配网络带宽。然而，在高质量的RTC中，高帧率减小了帧到达客户端的间隔时间，而高分辨率增加了每帧的解码延迟。在解码器队列中，帧到达率经常超过离开率，导致长队列。视频传输不仅需要根据网络带宽调整比特率，还需要与解码器队列容量协调。

通过对云游戏服务Tencent Start的测量，发现在不协调队列容量的情况下进行视频传输可能会在客户端解码器队列中引入不可忽视的排队延迟。此外，这种排队延迟占据了延迟较紧的高质量RTC满足要求中延迟帧的很大比例，特别是在最近的基础设施发展（例如边缘计算）已经减少了网络延迟的情况下。根据本文的测量，在总往返延迟大于100毫秒的所有帧中，有57%的帧在解码器队列中延迟超过50毫秒。我们的调查发现，未来对UHD和HFR视频的需求将进一步加剧这个问题，即使是在解码硬件进化的情况下（§3.1）。因此，对于高质量的RTC，为了减少端到端延迟，减少解码器的排队延迟是至关重要的。

本文展示了高质量RTC的变化，包括UHD分辨率、HFR以及严格的延迟要求。进一步在以下两个方面对这些提案进行了改进。首先，现有的控制机制是基于延迟或队列长度，这些机制反应较慢，因为它们需要等待队列的积累。AFR依靠到达和服务过程，以及队列长度来调整帧率，而不是仅仅依赖于延迟或队列长度。其次，并不是所有解码排队延迟的增加都需要降低帧率。例如，当排队延迟由于短暂的到达数据包突发而增加时。因此，AFR使用两个控制回路，以不同的时间尺度调整帧率。

本文的贡献如下：（1）进行了为期一个月的测量活动，以证明在解码器队列控制排队延迟的重要性，并确定了高质量RTC在满足严格延迟要求方面面临的独特挑战。（2）设计了一个分层的帧率控制器AFR，用于在高质量RTC的不同场景下控制解码器队列，以实现超短延迟。（3）使用基于轨迹的模拟和在实际生产环境中的大规模部署对AFR进行了评估。我们的评估结果表明，排队延迟和总的端到端延迟都可以显著改善。

2.动机和挑战


在本节中，首先解释高质量RTC中剧烈的排队延迟。然后，提出了对调整帧速率的设计选择的思考。进一步分析了有效实现超短队列的独特挑战。

2.1 剧烈的排队延迟

本文在图1中对交付流水线中每个阶段的每个帧的延迟进行了分析。在2021年对腾讯云游戏服务进行了一个月的测量，该服务包含数以万计的用户，拥有数千种不同的CPU和GPU型号。我们在图2中提供了CPU和GPU的发布日期和基准分数。根据本文的测量，在整个流水线中，网络、排队（在解码器队列处）和解码延迟在第99百分位数上都超过了10ms。

图1 RTC服务的一般交付流程（红色代表RTC端到端延迟的主要部分）

我们在图3中用红色突出显示了它们。应用程序和编码延迟的尾部较轻，因为它们在商用服务器上处理，与网络和异构客户端相比更稳定。因此，我们将在以下讨论中重点关注网络、排队和解码延迟。当分析传统RTC服务中T>200ms的帧的根本原因时，网络延迟可能是其主要原因（以红色阴影标出）。然而，当分析T>100ms的帧时，排队延迟主导了总延迟的增加。

图2 生产中用户设备的发布年份和基准得分分布

我们的测量结果显示，在所有端到端总延迟超过100ms的帧中，排队延迟的增加比所有其他组件的延迟更为频繁：其中57%的帧的排队延迟超过了50ms（图3中的星号）。

图3 网络延迟与排队延迟
与LFR流媒体相比，HFR通过减少帧之间的间隔时间增加了解码器队列的到达率。另外，UHD通过增加每帧的解码延迟，降低了与SD流媒体相比的离开率。具体来说，在图4中展示了队列利用率，来说明帧率和分辨率如何影响解码器队列的负载。本文评估了不同帧速率和分辨率，测量到达间隔时间和解码延迟的分布。正如我们所见，对于传统RTC服务（左下角），由于其低帧率和分辨率，解码器队列在尾部仍然具有ρ≪1的利用率。然而，对于高质量RTC应用（右上角），解码器队列将会负载沉重，导致严重的排队延迟。

图4 解码器队列利用率（99分位数）

图5中展示了来自我们生产服务的追踪数据。在追踪数据中，帧之间的间隔时间为16ms，解码延迟为18ms，而队列延迟平均为54ms。虽然解码延迟在数量上并不大（18ms），在持续时间上也不长（20帧，约0.3秒），但它会导致严重的队列延迟。如果这样的追踪数据的概率为1%，我们将会有一个99分位解码延迟为18ms，99分位队列延迟为55ms。在这种情况下，尾部的队列延迟远高于解码延迟，这也导致了绝大部分的端到端延迟增加。

图5 解码器累积队列

同时，用户对视频的需求急剧增加，如图6(a)所示。例如，YouTube支持的最高分辨率和帧率从2005年的360p@30fps（7Mpx/s）增加到2015年的8K@60fps（2Gpx/s），平均每14个月翻一倍。在16K 或240fps的新兴服务进一步表明了对UHD和HFR流媒体的未来需求。然而，硬件的解码速度并没有以同样的速度增加。如图6(b)所示，最先进的解码硬件的解码速度在大约27个月内翻一倍（蓝色虚线）。同时，我们还通过将图6(a)中估计的分辨率和帧率相乘来计算视频现有需求所需的解码速度，并在图6(b)中以红色绘制出估计值。从需求来看，解码速度每20个月翻一倍（红色虚线），增速远快于解码硬件的发展（蓝色虚线），这表明解码硬件对UHD和HFR视频仍然存在持续的能力不足。

图6 解码硬件已经不能满足人们对高分辨率和高帧率视频需求的快速增长

2.2 独特挑战

（1）实现超短排队延迟。为了实现解码器队列的超短排队延迟，挑选适当的指标来通知控制器何时采取行动是一个具有挑战性的问题。现有的信号（队列长度  或排队延迟）无法实现超短排队延迟。由于解码器队列的积累是到达或离开过程的波动的结果，队列长度和排队延迟都只能在队列已经积累起来时被观察到。在图5的示例中，虽然解码延迟在第3帧开始增加，但只有到第9帧时才能观察到非零的队列长度。为此，我们希望捕捉最早的信号以预测潜在的排队延迟增加。例如，受到拥塞控制领域的最新进展的启发，一个直接的方法是测量解码器队列的出队速率，以估计潜在的排队延迟增加。然而，就尾部而言，到达过程也在波动，这也可能导致排队延迟的增加。例如，网络延迟的99分位数可能比中位数高出十倍。因此，为了精确地避免队列积累，我们AFR全面测量到达和离开过程，并基于排队理论控制排队延迟。

（2）处理各种事件。高质量RTC中解码器队列的形成原因是复杂的。解码容量的稳态下降可能导致解码器队列的积累，例如图5中的跟踪数据。此外，解码器队列也可能由于瞬态情况而积累。例如，根据我们在生产中的经验，解码器可能会突然经历约100毫秒的解码延迟（例如图7(a)中的第3帧）。无线通道中突然的干扰也可能导致多帧的突发到达（例如图7(b)中的第4到8帧）。在这两种情况下，解码器队列将被积累。由于这些瞬态波动突然发生，控制器通过测量入队和出队速率来做出反应具有挑战性。因此，AFR区分了队列积累的原因，并分别对不同时间尺度上的波动做出反应。我们设计了一个静态控制器来避免在高流量情况下积累队列，以及一个瞬态控制器来减少在意外情况下的排队延迟。

图7 解码器队列的瞬态波动

3. AFR系统设计与性能评估

3.1 系统设计

算法1中给出了AFR的工作流程。具体地说，静态控制器（行1）基于入队和出队过程的动态来维持超短目标周围的队列。通过测量两个过程的统计量，AFR基于排队论计算排队延迟的期望值。因此，可以针对给定的排队延迟目标来优化帧速率。瞬态控制器观察队列状态Q（队列长度和队列延迟）并计算折扣因子α （行2）以在队列公式化时进一步降低帧速率。最终帧速率是固定帧速率乘以α折扣因子（行3）。在这种情况下，AFR可以对队列累积的各种场景做出反应。

由于静态控制器和瞬态控制器的建模十分复杂，感兴趣的读者可以参见原文。此处，我们只简要的介绍其基本的算法原理。静态控制器使用了Kingman公式（Kingman公式是G/G/1队列中广泛采用的排队延迟近似公式）作为排队延迟的期望值的近似。

目标帧率可以建模为：

除此之外，还需要测量到达和服务过程的均值和方差。类似于TCP 中的RTT测量，我们采用指数加权移动平均（EWMA）和指数加权移动方差（EWMV）来估计等式中的µs，σs，µa，σa。

瞬态控制器设计用于处理偶然队列累积，其中K_2帧到达时，K_1的逗留时间和队列长度L_Q如下表示：

3.2 实验评估

主要在以下几个方面对AFR控制器进行了评估：（1）延迟改进。我们展示了性能改进情况：AFR的长排队延迟帧比例和总延迟与现有基线相比已提高2.1×-26×和13%-2.2×（2）帧率稳定性。我们随后展示了AFR对与帧率相关的指标影响微乎其微。（3）参数敏感性。我们的评估表明，AFR中的参数具有广泛的设置范围，可以在性能优化上获得比调优基线更好的效果。

在图8中给出了99百分位排队延迟和排队延迟> 50 ms的帧的比率。我们首先分析AFR对三种现有机制（DropTail，QLen-S和QWait-S）的结果。AFR可以将99%的队列延迟降低1.9倍至7.4倍，并且在不同的轨迹集合上相对于三个基线将严重排队帧的比率降低2.1倍至26倍。在这种情况下，99%的排队延迟可以被压缩到6.9ms。这表明AFR可以有效地实现超短的排队延迟。AFR还展示了令人满意的总端到端延迟的性能改进，这与用户的体验直接相关。

图8 排队时延的仿真结果

此外，我们还测量了AFR对帧速率的影响。我们首先在客户端上的每个帧到达时测量帧之间的到达间隔时间。例如，60 fps的帧速率应导致约16.7ms的到达间隔时间。我们调整每个算法的参数，以使其到达间隔时间的第99百分位数保持在相同的水平。因此，对于第10- 90百分位数，如图9（a）所示，除DropTail外，大多数算法具有可比性。与现有部署的机制DropTail相比，AFR甚至由于其更好的帧丢弃管理而提高了尾部用户感知的帧速率。AFR略微降低了3%-9%的中值帧速率，考虑到延迟的改善，这给用户带来的体验质量（QoE）下降可以忽略不计。我们进一步测量帧速率的平滑度，这也可能对用户的体验产生潜在影响。我们测量到达间隔时间的差异作为帧速率平滑度的指标，并在图9（b）中呈现结果。除DropTail外，所有基线和AFR具有相似的到达间隔差，并且优于DropTail。这主要是因为DropTail中的帧丢弃将引入到达间隔差的突然增加。此外，我们还测量帧调整间隔并在图9（c）中呈现分布。AFR的中值调整间隔为数百到数千帧，这比帧速率调整的响应时间长得多。

图9 帧率稳定性

接着，我们对AFR和其他基线算法的参数敏感性进行了评估。我们对所有基线算法的参数进行了调整：QLen-S和QWait-S的跳帧阈值等。我们在图10中呈现了在Cat.(1)跟踪中具有排队延迟>50ms的帧的比率（P(Q>50ms))以及99th百分位数的到达时间。从图中可以看出，在广泛的设置范围内，AFR优于所有其他基线算法，在排队延迟和帧率之间实现了更好的权衡。基于队列长度的算法在实现超短排队延迟方面面临挑战：使用极端参数（只要队列长度为非零，就跳过/降低帧率），QLen-S和AFR-QLen的P(Q>50ms)分别为2.2‰和1.7‰，远高于其他基线算法。这与我们分析相符，即队列长度作为控制队列的超短目标的信号过于粗粒度。与基于帧率的算法相比，基于跳帧的算法可以实现更低的排队延迟，但到达时间更长。

4. 结论


综上所述，在本文中，我们提出了自适应帧率（AFR）来通过动态调整帧率来降低高质量RTC的解码器队列的排队延迟。AFR引入了一个静态控制器和一个瞬态控制器，分别用于减轻静态的高负载流量和突发性的到达和服务。我们进一步通过基于轨迹的模拟和在生产集群中的部署评估了AFR的性能。实验表明，AFR可以显著降低卡顿比例和尾部总延迟。


代码链接：

https://github.com/transys-project/afr

论文链接：

https://www.usenix.org/conference/nsdi23/presentation/meng





助手微信



诚邀国内外优秀导师发布招生信息
诚邀国内外优秀论文作者发布文献解读类原创文章
诚邀有恒心同行共同维护公众号
转载与合作，请加助手微信/131 8805 0268


内容中包含的图片若涉及版权问题，请及时与我们联系删除