WCNC 2020 | 在交互式视频会话中动态调整 jitter buffer 以降低延迟

在分组网络中，通常使用缓冲区来消除网络抖动，并以牺牲额外的延迟(即抖动延迟)为代价实现平滑的视频播放。在这项工作中，我们研究抖动缓冲区如何在 Web 实时通信(WebRTC)中执行，这是交互式多媒体应用程序中使用的事实标准。我们从一个采用 WebRTC 的实时视频流服务提供商那里收集数据集。通过对数据集的深入分析，我们发现抖动缓冲区可以动态调整抖动延迟，但是抖动延迟过于保守，导致抖动延迟的下降非常缓慢。为了解决这个问题，我们分析了抖动缓冲区的控制逻辑，发现原因在于使用了一个固定的降阶因子，称为 psi ()。提出了一种增强的抖动缓冲自适应机制 JTB-，该机制根据帧大小和帧持续时间动态调整 ，以合理地加快抖动延迟的下降速度。实际测试表明，在不同的网络条件下，JTB- 方法的抖动延迟比固定 方法降低了41.5% ，接收帧速率、量化参数(QP)和发送比特率均有所提高。

近年来，实时音视频领域发展迅速。视频内容提供商需要提供跨不同客户端设备的无缝多媒体体验。WebRTC 为 PeerConnection 的实现提供实时音频和视频处理功能，IETF RTCWEB 工作组[1]支持 WebRTC，以标准化协议和 API。WebRTC 可以实现跨多个 Web 浏览器、平台和设备的统一实时通信，并且已经在主流浏览器和移动平台上提供。与此同时，WebrTC 被许多应用程序采用，如谷歌视频聊天、 Whatsapp 和 Facebook Messenger。尽管 WebRTC 在世界范围内发展迅速，但是在尽最大努力的网络(最大努力交付描述了一种网络服务，在这种网络服务中，网络不提供数据交付或交付满足任何服务质量的任何保证)下提高 WebRTC 的服务质量(QoS)仍然是一个需要解决的主要挑战[2]。

真正的网络环境通常是复杂的，导致数据包以不同的延迟(即抖动)到达接收端。如果每个接收到的数据包都立即播放完毕，只要网络稍有变化，视频就会加速或减速，甚至卡住。我们需要为一个更平滑的视频缓冲传入的数据包，这引入了一个延迟(称为抖动延迟)。较大的抖动延迟可以更好地消除网络抖动的影响，但会增加网络延迟，降低视频的实时性。根据 ITU-T G. 114[3]标准，在交互式 RTC 中，150ms 单向延迟的目标是至关重要的，因此抖动缓冲区应根据需要增加或减少抖动延迟。然而，直播视频流服务提供商的用户反馈表明，即使网络状况良好，有时也存在一种延迟感。所以这个问题是本文工作的动机。

在本文中，我们使用我们的数据集的一部分，过滤的16129个实时流会话来分析抖动缓冲区的性能。数据表明，即使网络质量良好，抖动时延在突然增加后下降很慢，这是非常不必要的。抖动缓冲区从传输时间变化和网络抖动两个方面来评估抖动延迟。前者受帧大小差异的影响。从会话开始就维护最大帧大小 。当当前帧大于 时，当前帧被认为是一个较大的帧，否则 将以固定的速率减小。从设计思想上看，抖动缓冲器只考虑了抖动时延随着大帧的到达而迅速增加，随着网络抖动的变化而变化，而没有考虑快速合理地降低抖动时延。然而，我们假设，由于固定 不能适应当前的相关信息，动态适应 应该会有更好的性能。

为了提高抖动缓冲区的性能，我们提出了一个 JTB- 模型，以适应 的降低因子 ，使 以更快的速度降低，从而快速降低抖动延迟。值得注意的是，JTB- 不影响网络抖动对抖动延迟的影响。我们根据两个方面对 进行动态调整: (i)大帧与普通帧的尺寸差，表示需要减小尺寸的大帧数量，确定 的初始值。差异越大，初始值越小，抖动延迟下降越快。 (ii)大帧的持续时间，使 随着大帧的持续时间缓慢减小。

我们在 WebRTC 框架中实现了我们的模型，并进行了一系列的实验。由于没有其他算法来改善 WebRTC 的抖动缓冲区，我们将实验结果与默认的抖动缓冲区进行了比较。结果表明，整体平均抖动时延降低了约41.5% 。然而，在弱网络下，JTB- 的性能更为突出。

本文的其余部分结构如下: 第二部分回顾了有关实时视频通信延迟控制的相关文献。第三节介绍了抖动延迟的调整，并描述了我们的 JTB- 模型。第四节分析了所收集的跟踪数据集的网络质量，并给出了我们的实现和定制的测试平台。我们在第五节中对 JTB- 进行了评估，并在第六节中对本文进行了总结。

为了提供最佳的服务质量(QoS) ，实时应用程序应该具有高吞吐量和低延迟，同时不会引起拥塞，这对于容易出错的 Internet 是一个巨大的挑战[4] ，[5]。目前，学术界和业界对 WebrTC 的研究[6]、[7]主要集中在拥塞控制和服务质量的测量方面，但尚未进一步研究和优化 WebrTC 的抖动缓冲机制。特别是 IETF 工作组 RMCAT 在 RTP 之上设计了三种拥塞控制算法。这些算法的目标是在保持尽可能低的队列延迟的同时，收敛到最大可用带宽。

减少延迟对于实时应用程序的 QoS 非常重要。我们发现，在其他实时应用中，已经提出了许多方法来减少延迟。除了减少排队延迟外，还可以减少编码延迟[8]和缓冲区延迟。VPAP [9]根据估计的网络吞吐量动态计算所需的最小可能的播放缓冲区，并允许提前开始播放，同时避免缓冲区运行不足。动态抖动缓冲区能够快速适应不断变化的条件，并在考虑丢失数据包之前预测它应该等待多长时间。许多研究人员已经在抖动管理领域进行了研究。文献[10]-[12]使用当前网络条件(比特率，延迟变化)的接收数据包来评估适当的延迟。文献[13]提出了一种基于网络流量预测的自适应抖动缓冲控制算法。

WebRTC 框架中的抖动缓冲区具有减少缓冲区延迟的过程(抖动延迟) ，但是它以一个固定的比例来减少抖动延迟，这是过于保守和不必要的。受到上述文献，特别是 VPAP 的启发，它最小化了播放缓冲区，同时避免了播放中断。为了合理、快速地降低抖动时延，提出了一种动态调节抖动时延下降速度的 JTB- 模型。

在本节中，我们将介绍 WebRTC 中使用的抖动缓冲区，并重点介绍如何调整抖动延迟。抖动缓冲区收集和构造传入的媒体数据包。一旦帧完成，缓冲区估计帧在传递给解码器和播放之前应该在缓冲区中等待多长时间。等待时间是抖动延迟，这会影响端到端延迟和会话质量。如果抖动时延过大，实时性会降低。如果抖动延迟过小，消除抖动的效果将会减弱，视频播放将会不稳定。延迟正日益成为 RTC 应用程序的性能瓶颈。有必要合理地调整抖动延迟。接下来，我们首先在实际应用中说明了 WebRTC 中抖动延迟控制的性能问题。然后我们通过分析 WebRTC 码库中抖动延迟的控制逻辑来定位问题。最后，我们设计了一个新的模型来解决这个问题。

网络抖动对抖动延迟影响很大。我们首先观察在良好网络条件下的轨迹，了解抖动延迟的趋势。为了获得更好的描述，我们从数据集中选择一个典型的跟踪作为示例。我们提取本次会议的前800秒。这个会话的网络质量非常好，平均 RTT 为26ms，并且没有丢失，但是抖动延迟不是特别好，如图1所示。从图中的虚线框可以看出，将抖动延迟减少45毫秒需要将近300秒(即从140秒到435秒)。我们对这一现象的看法是，在这样一个良好的网络下，抖动延迟下降得太慢，应该能更快地恢复到平均延迟。为了找出问题的根本原因，我们分析了抖动延迟调整的逻辑。

抖动延迟被认为有两个组成部分: (i)传输时间变化和(ii)网络抖动 ，两个单位都是毫秒。前者适用于帧的尺寸差和链路容量。源代码中抖动延迟的计算如下:

其中 时自从会话开始收到的最大帧大小。 时当前时间段的平均帧大小， 时当前瓶颈链路容量，单位是 ，通过卡尔曼滤波直接和间接得到因子和 。下面我们重点讨论帧大小对抖动延迟的影响。

帧大小的影响。从等式(1)可以看出来，jitter delay 被 影响。大尺寸的帧比小尺寸的帧需要更多的时间通过连接传输。这反映了帧的抖动大小会影响到达延迟的抖动。为了消除这部分抖动并平滑抖动延迟，jitter buffer 不考虑当前帧大小与前一帧大小之间的差异，而是考虑最大帧大小 与平均帧大小 之间的差异。怎么维护这两个值将在后面详述。当一个帧到达时，只有当帧大小在正态分布的两个标准偏差之内时，平均帧大小 才会更新。权重 固定在，Lavg 的最新情况如下:

其中 是当前帧大小。而 是每一帧到来后都会更新的。当 大于 时， 将被更新为 ，然后将当前帧视为大帧，否则它将以一个固定的 比例减小。但是 ，这就意味着在一个大帧出现后，将会用很长的时间才能回落到 。

1)基本思想: 从上述抖动延迟的分析来看，抖动延迟下降缓慢的主要原因是 的固定下降率设定为。在这种情况下，Lmax 必须在一个固定的速率 下降，不管大帧的大小和持续时间，导致 缓慢下降，然后导致抖动延迟的缓慢下降。直观地说，使用固定 并不是最优的。动态调整比 可以有效地加速抖动延迟的下降，并对整体性能产生积极的影响。

2)算法设计：我们注意到 主要被两个因素影响： 和 在大小上的差异以及大帧的持续时间。这两个因子分别决定了 和 的值，它们的值属于。具体而言，自适应 的定义如下:

其中 是两个因子的权重， 是 的下限。参数值 和 的确定将在下面详细解释。

参数值的确定: 通过比较不同 的影响来确定 最小值。以图 1 中的网络轨迹为例， 和 的平均值分别为 和，平均接收帧速率为 。我们设置不同的 并记录从 到 所需的迭代次数和时间。

正如我们从表 I 中看到的，这两个指标的值在原始值(0.9999)下太大，并且它们会随着 减少而急剧下降。我们可以推断，小的 更好，但如果我们设置为 ，这将导致抖动延迟下降太快，并可能增加抖动频率。最后，我们将 设置为，并将 设置为上限。由于 和 的上限都是1，为了在区间内调整 ，我们把 作为 。

帧大小: 的影响反映了 降低的程度，影响了 的初始值。 是根据 和 之间的差值更新的，其定义为 。由于自然指数函数 不需要额外的因子，当 时，。 的计算如下:

， 随 的增加而减小。因此， 和 之间的差异越大， 的值就越小，使 为 或 ，而不是固定 情况下的 。换句话说， 允许 以较小的初始速率进行大幅度减少，从而导致更快的抖动延迟减少。

帧持续时间的影响: 很自然地知道，随着大帧持续时间的增加，下降速率需要增加，因为 将越来越接近 。 以秒为单位记录大帧的持续时间，然后 表示大帧持续了多少分钟。基于这个思想，我们得到了 的公式如下:

注意， 是与帧无关的，所以当下一个大帧还没有出现时， 继续下降， 的减少在相同的 下是相同的。

这里我们可以得到如算法 1 所示的 JTB- 的总体设计。值得注意的是， 随着时间的推移而减小(是一个累积的大帧持续时间)，但是 在下一个大帧出现之前不会更新。换句话说，在 下降过程中，只有 的初值不同，它受 的影响，然后由于 的存在而减小。

在这里，我们分析了一般网络条件的质量收集数据集，并介绍了比较评价的实验平台。

在获得实时视频聊天服务提供商的许可后，我们访问其内部数据分析平台并抓取其全球实时数据。对于每个会话，跟踪记录每秒的流量数据，如 RTT、丢包率和抖动延迟。我们运行爬虫并捕获2018年6月29日所有实时会话的流量数据。为了呈现抖动延迟的总体趋势，我们筛选出超过10分钟的会话，最后收集16129个会话，总共2537390个小时。

会话质量分析: 执行一些度量以了解所选会话的网络质量。 据统计，大约75% 的会话使用 Wi-Fi，其余使用4G。我们以每个会话的平均 RTT 和平均数据包丢失率作为质量标准，分析它们在4G、 Wi-Fi 和所有会话下的累积分布。 如图 2 所示，可以观察到，在所有会话中，90.9% 的会话的平均 RTT 小于150ms，88.5% 的会话的平均数据包丢失小于2% 。平均 RTT 小于150ms 的4G 和 Wi-Fi 会话的概率分别为82.4% 和93.5% 。同样，4G 和 Wi-Fi 会话的平均丢包率低于2% 的概率分别为84.0% 和89.6% 。因此，我们可以推断: (i)大多数会话具有良好的网络质量，(ii) Wi-Fi 会话具有比4G 会话更好的通信质量。

图 3 显示了我们的测试平台，它由两台计算机(即一对发送器和接收器)通过有线网络连接而成，丢包率为零，平均 RTT 为1-3ms。在 WebRTC 源代码中，我们将发送比特率的上限配置为 2Mbps 以匹配跟踪，并在抖动缓冲区中添加动态调整 的逻辑。我们在 Ubuntu Linux 操作系统上编译 WebRTC。为了验证实验的可重复性，我们从 Youtube 上选择了一段名为 Piper [15]的公开视频，持续时间约6分钟，并在实验中传输这段视频序列。发送方是一个工作站，承担以下任务: 1)利用流量控制[16] ，根据数据集的流量数据控制 RTT 和丢包率，模拟真实的网络环境。2)它使用 V4l2loop-back [17]来创建一个虚拟视频设备。在接收机中实现 JTB- 模型，以调整 的值并记录抖动缓冲区的指标。为了评估 JTB- 和原始抖动缓冲区(JTB)的性能，我们计算每个会话的度量，如表 II 所示。值得注意的是，量化参数(QP)控制保存多少空间细节，范围从0到51。QP 越小，保留的细节越多，视频质量越高。

为了评估 JTB-，我们使用图3中描述的实验台，从数据集中随机选择100个会话，其中 4G 和 Wi-Fi 会话各占一半。对于每个会话，我们使用前六分钟来模拟真实的网络环境，并将这两个模型与前一节中定义的指标进行比较。为了方便起见，我们使用 JTB (Jitter Buffer)来表示原始模型。

为了分析两个模型的总体性能，我们计算了100个会话的相应指标的平均值。图4显示了 JTB (蓝色)和 JTB- (黄色)产生的抖动延迟(延迟)、接收帧速率(FPS)、量化参数(QP)和发送比特率(比特率)的平均值。与 JTB 相比，抖动延迟从149.76 ms 下降到87.64 ms，降幅约为41.5% ，而其他三个指标变化不大。接收帧率和发送比特率分别提高了2.14 fps 和0.26 Mbps。QP 下降了0.36，这意味着保留了更多的空间数据。总的来说，JTB- 可以提高实时视频质量。

探索性能更好的情景: 为了更好地理解 JTB- 的性能优势，我们得到了 JTB 和 JTB- 模型每个会话的平均抖动延迟，两个值之间的差异是抖动延迟下降。我们根据 4G 和 Wi-Fi 类型绘制抖动延迟下降的累积分布图，如图5左侧所示。据观察，4G 会话(91.3 ms)的平均抖动延迟下降幅度高于 Wi-Fi 会话(62.1 ms) ，4G 和 Wi-Fi 会话下20% 抖动延迟下降幅度分别超过96 ms 和156 ms。结合图2，进一步说明了4G 信号比 Wi-Fi 信号更弱，并且我们推断在弱网络中抖动延迟减少得更多。然后选择丢包率来反映网络质量，计算所有100个会话的丢包率分布，其中50% 会话的平均丢包率小于0.5% 。我们根据0.5% 的损失将100个会话分为两组，并在图5中绘制出正确的图表。数据显示，100个会话的抖动延迟(黑色)减少了76毫秒，对于平均损失小于0.5% (蓝色)和大于0.5% (红色)的会话，抖动延迟减少了44.4毫秒和104.9毫秒。 结果表明，在丢包率较高的会话中，抖动延迟的降低更为明显，基于丢包率的抖动延迟下降的 CDF 比基于信号类型的抖动延迟下降的 CDF 更为明显。 通过以上分析，我们得出结论，提出的动态 机制在不影响视频质量的情况下有效地降低了抖动时延，并且在弱网络中具有更好的性能。

为了更好地说明动态 对 JTB- 性能的影响，我们从实验中选择了两个典型的会话，一个在平均 RTT 为25ms 和零丢包的强网络和平均 RTT 为40ms 以及丢包率为 2.9% 的不稳定弱网络下，如图6所示。图7  显示了 JTB (蓝色)和 JTB-ψ (红色)产生的抖动延迟、缩减因子 、最大帧尺寸 和大帧持续时间 ，而图8显示了两个会话的其他指标(量化参数、接收帧率和发送比特率)。

抖动延迟比较: 根据图 7 中强网络和弱网络的四个度量趋势的相似性，我们观察到1) JTB- 的抖动延迟比 JTB 低，在强网络中，抖动延迟的平均值从106.43 ms 下降到92.16 ms，下降了13.4% 。在弱网络中，抖动时延的平均值从242.65 ms 下降到105.32 ms，下降了56.6% 。2)动态 随着 的增加而减小，而 JTB- 的 和抖动延迟的下降幅度更大。例如，在强网络会话的情况下，从 秒到 秒，JTB 用了170秒将 减少 20 KB，抖动延迟减少 45 ms，而 JTB- 用了125秒将 减少 50 KB，抖动延迟减少 120 ms。

QoS 比较: 图8显示了其他三个指标在强网络和弱网络中的曲线，反映了视频质量，从中我们可以提取以下信息: 1) JTB- 下的 QP 平均值与 JTB 相比变化不大，JTB 在强网络中减少了1.6，在弱网络中增加了0.1。2)在强网络中，接收帧率的值和范围与 JTB 基本相同。在弱网络中，虽然在 JTB- 下帧速率略微降低了2 fps，但是帧速率的抖动减小了。3)在强网络中，JTB- 下的发送比特率保持在2Mbps 的上限。在弱网络中，由于 RTT 抖动和丢包率较大，JTB 下的发送比特率经常下降。然而，JTB- 抑制了发送比特率的下降，并将平均发送比特率从 1.16 Mbps 提高到1.66 Mbps。可以看出，在强网络中，JTB 和 JTB- 的整体性能是相似的，JTB- 下的 QP 得到了改善。在弱网络环境下，QP 性能和接收帧率略有下降，影响不大，但发送比特率有很大提高。

综上所述，JTB-自适应调整，显著降低了各种网络条件下的抖动时延，并不同程度地改善了其他指标。特别是 JTB- 在弱网络下表现更为突出。

本文研究了低延迟交互式实时视频聊天应用中抖动缓冲区的性能问题。分析了抖动缓冲区的控制逻辑和实际视频服务提供商的跟踪数据集，证明了在抖动缓冲区中使用自适应 加速抖动延迟下降的必要性。为了解决这个问题，我们提出了一个 JTB- 模型来动态设置因子 ，并与默认的抖动缓冲区进行了实验比较。结果表明，JTB- 模型可以在不同的网络条件下提高实时视频的性能。