摘要
超高清晰度实时通信(UHD)用户在高帧率和高比特率的情况下，有时会出现严重的服务退化问题。由于在客户端传入和解码帧时的波动，在客户端流解码器之前可以形成一个解码器队列。这些波动很容易使解码器队列超载，并对这些队列帧引入明显的延迟。本文提出了一种帧跳跃机制，通过主动管理解码器队列中的帧，有效地降低了队列延迟。在保证视频编码解码质量的同时，我们对帧进行跳频优化，以保持端到端的时延。我们还用马尔可夫链数学地量化了潜在的性能。我们基于网络 trace 在 UHD RTC 的仿真环境下的评估帧跳跃机制的性能。实验结果表明，跳帧可以使解码器严重队列延迟比率降低 23 倍，使较为严重的总体延迟比率降低 2.6 倍。
简介
随着 2019 冠状病毒疾病对高清晰度及互动式视频流媒体的需求日益增加，超高清(UHD) 实时通讯 (RTC) 流媒体所共享的网络容量显著增加。这些 UHD RTC 服务，如 UHD 远程会议，虚拟现实和云游戏，现在吸引了学术界和工业界的注意。为了满足用户的需求，UHD RTC 服务的目标是提供高比特率(高达30mbps)和高帧速率(高达60fps)的流媒体服务，同时提供超低的交互延迟帧率。
现有的流媒体传输流水线可以满足传统的流媒体服务，如 4k 视频流。然而，在高帧速 UHD RTC 业务下，这种传输管道可能是次优的。例如，由于网络抖动和解码时间的变化，客户端的流式解码器可能无法及时解码视频帧。在这种情况下，当新帧在解码前到达时，新帧必须在解码前排队。这种解码队列的形式可能会对排队帧引入较高的队列延迟。高帧频以及网络抖动将导致视频帧的突发传入，从而使队列瞬间超载。而高比特率意味着视频帧更加复杂，这可能会增加解码时间。这些原因将导致解码器队列的排队延迟数十毫秒 ，甚至更长。随着来自应用程序的实时通信需求的增加(例如，在虚拟现实应用程序中不到 20 毫秒) ，这种巨大的解码器队列延迟变得显而易见，需要消除。
本文福利， 免费领取C++音视频学习资料包、技术视频/代码，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓
然而，由于以下原因，管理解码器队列以实现低延迟和高图像质量是非常重要的。简单的解决方案包括控制解码器队列的到达速率(即帧速率)或服务速率(即解码时间)。然而，由于编码器和解码器位于距离较远的地方，由于控制回路(包括中间网络延迟，编码器的有效延迟)的影响，动态改变编码参数是一个挑战。因此，动态调整帧速率(以降低帧的到达率)或比特率(以加快帧的解码时间)是不够及时的。
因此，在主动队列管理(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)。
图3 参考帧重新排序。蓝色箭头表示用于预测被编码帧的参考帧。
在对编码器参考帧序列重新排序后，为了保证丢弃后的解码质量，有些帧不能用来预测后续帧。因此，当我们提取解码器队列中相邻帧的图片组(GoP)容量时，必须有一个基层帧(图3(b)中的黑帧0、2等)。由于基本层帧是唯一用于预测下列 GoP 帧的帧，因此仅对基本层帧进行解码并在 GoP 中丢弃其他帧不会损害解码质量。
跳过哪些帧？在具有丢弃解码器队列中帧的能力后，我们提出了主动队列管理(AQM)——跳帧算法，以有效地消除解码器队列延迟。
在 Frame-Skipping，我们会选择在排队时丢弃较早的帧，而不是像广泛使用的尾部丢弃 AQM (RED，PIE，等等)那样在排队时丢弃最新的到达帧。这是因为我们的目标是保持较低的队列延迟，而不仅仅是较低的队列长度，丢弃较早的帧，和渲染最新的帧可以提供较低的延迟流。
更具体地说，当解码器队列超载时，我们将在解码器队列的头部提取相邻帧的 GoP 量，然后只解码一个并跳过(删除)其他相邻帧。直观地说，同时提取更多帧意味着更有效地消除解码器队列延迟，但也意味着更多帧将被丢弃(更多的网络带宽浪费)。他们之间会有一个平衡。
跳过多少帧呢？为了达到平衡，在 FrameSkipping 中，我们提供了一个称为跳过率
的参数，它表示丢弃帧比例的期望值。所以提取帧的数量是
在这一部分，我们将讨论未来的可行性和跳帧的特点。
未来的可行性。帧跳过利用 SVC 扩展或 NVIDIA 编解码器 API 来重新排序编码器缓冲区，以有效地消除解码器队列延迟。因此，我们想知道是否仍然可行的编码器缓冲区重新排序与编解码器标准升级的未来。可适性视讯编码(SVC)扩展现在支持 H.264和 H.265标准 ，也支持全新的 H.266标准。另一方面，无论将来采用什么样的编解码标准，我们仍然可以利用编码器的 API 直接使编码器缓冲区中最近的图像失效，从而重新排序编码器缓冲区。
高级队列管理。许多研究也关注于通过部署队列管理来改善流服务体验。例如，控制器将改变网络数据包的发送速率，以保持较低的因特网队列延迟。但是解码器队列是在视频帧水平上工作的，一个队列帧在60fps 的流下可能引入16ms 的延迟。因此，与排队的网络数据包相比，它将更加引人注目。
此外，那些关注帧级别的队列管理位于服务器的编码器端。因此，长控制环路将限制解码器队列延迟的消除效率，正如我们前面所讨论的。然而，我们的客户端跳帧机制可以立即有效地消除突发队列波动。
跳帧场景。在本文中，我们利用 SVC 和编码器的 API 在解码前跳过视频帧而不损害图像质量。此外，一些用例还受益于视频丢弃，如视频分析。然而，跳帧和视频分析中丢弃帧的对象是完全不同的。跳帧技术旨在通过消除队列延迟来实现超低延迟的实时通信。另一方面，视频分析正在过滤/丢弃帧，以解决视频流和分析模型的高计算和网络资源需求的挑战。优化对象的差异性使得不同场景下的帧丢弃调度不同。
总结
本文提出了一种跳帧机制，通过在跳帧队列头部提取相邻帧，有效地消除解码器队列延迟。我们还引入了一个数学模型来量化跳帧性能，并提供了一些推荐的跳帧率。然后，通过在网络模拟器上对跳帧进行评估，证明跳帧可以有效地降低译码器队列延迟和总延迟。
本文福利， 免费领取C++音视频学习资料包、技术视频/代码，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓