基于 QUIC 的 HTTP 自适应流媒体的可扩展高效视频编码 | EPIQ 2020

HTTP/2已经被广泛研究用于自适应视频流传输，但仍然存在由于TCP引起的先行阻塞和三次握手延迟的问题。与此同时，运行在UDP之上的QUIC可以解决这些问题。此外，尽管已经提出了许多适用于可扩展和非可扩展视频流传输的自适应比特率（ABR）算法，但文献中缺乏同时针对这两种视频流传输方法设计的算法。本文研究了QUIC和HTTP/2对ABR算法性能的影响。此外，提出了一种有效的方法，结合了传统的视频流传输方法（基于非可扩展视频编码格式）和一种重传技术，以利用可扩展视频编码格式进行自适应视频流传输。实验结果表明，在丢包和重传的情况下，QUIC从这种方法中获得了显著的好处。与HTTP/2相比，它提高了平均视频质量，并提供了更平滑的自适应行为。最后，本文证明了最初针对非可扩展视频编解码器设计的方法在可扩展视频（如可扩展高效视频编码，SHVC）上也能有效地工作。

作者：Minh Nguyen, Hadi Amirpour, Christian Timmerer,Hermann Hellwagner
来源：EPIQ 2020
标题：Scalable High Efficiency Video Coding based HTTP Adaptive Streaming over QUIC
链接: https://dl.acm.org/doi/10.1145/3405796.3405829
内容整理：鲁君一

引言

HTTP/2是由互联网工程任务组（IETF）进行标准化的，Mueller等人在HTTP自适应流媒体（HAS）环境下对其进行了评估。它具有几个关键功能，包括服务器推送，多路复用，流优先级和流终止。然而，由于HTTP/2运行在传输控制协议（TCP）上，它仍然存在先行阻塞（HOL blocking）问题，这可能会在数据包丢失的情况下对用户体验产生不利影响。此外，连接建立的三次握手延迟仍然存在。另一方面，QUIC协议运行在用户数据报协议（UDP）之上，而不是TCP，能够解决这些问题。最近，QUIC已被采纳为HTTP/3的传输协议。

已经提出了许多在HAS中用于自适应比特率（ABR）算法，以便根据用户的上下文条件（如网络条件）调整视频质量，以避免缓冲区耗尽等问题。这些算法可以分为三类，即：基于带宽的算法，基于缓冲区的算法，以及混合自适应算法。它们主要设计用于非可扩展或可扩展视频编码（SVC）格式。因此，文献中缺乏能够处理非可扩展和SVC格式的ABR算法。

过去，提出过一种基于HTTP/2的非可扩展视频重新传输技术（H2BR），用于HAS环境中的视频流传输。如果未来的吞吐量和当前缓冲区有利，低质量片段将被更高质量的片段（即额外的（重新传输的）片段）替换。通过多路复用，额外的片段和接下来的片段同时下载，并由流优先级进行控制。在HTTP/2中使用非可扩展视频编码格式实现H2BR具有两个缺点：低质量片段被更高质量版本替换，造成带宽浪费；由于使用相同的TCP连接同时下载额外的片段和接下来的片段，导致先行阻塞。为了解决这些缺点，本文提出在HAS环境中也采用H2BR用于SVC格式，并使用QUIC协议来处理先行阻塞问题。SVC格式允许通过向视频基本层添加视频增强层逐渐提升质量级别，而不是替换已下载的片段。

总之，本文的贡献有两个方面：

• 系统比较QUIC和HTTP/2在多路复用功能方面的差异，特别是在同时下载额外的SHVC层以改善质量方面的应用。
• 提出了一种非可扩展视频流传输ABR算法结合额外下载技术的方法，不仅可以提高视频质量，还可以提供平滑的自适应行为。

算法

ABR算法

在本文中，我们专注于两种ABR算法，即AGG算法和Backfilling算法，分别针对非可扩展和可扩展视频流传输提出。

AGG算法是一种基于吞吐量的算法，它以积极的方式（因此命名为AGG）选择低于下一个片段的预估吞吐量的最大比特率。先前的工作中的实验结果显示，将AGG算法与之前提出的扩展组件H2BR结合使用以传输非可扩展视频时，可以提供相对较高的整体QoE分数。为了将这种方法应用于可扩展视频流传输，客户端选择下一个片段的最大层数，使总比特率低于预估吞吐量。然后，从基础层（BL）到顶层增强层（EL），逐个获取该片段的各个层。在当前片段的所有层都下载完成后，此过程将重复进行以获取下一个片段。

在Backfilling算法中，客户端始终检查缓冲区中的BL数量。如果缓冲区包含所有的BL，自适应算法将从最后播放时间对应的片段开始提高片段的质量，通过下载其下一个EL。否则，首先下载最早播放时间对应的片段的BL。当缓冲区大小为五个片段时，在下载了所有这些片段的BL之后，该方法开始下载第五个片段的第一个EL，然后转向第四个片段的下一层。当完全下载第一个片段的第一个EL时，将获取第五个片段的第二个EL，依此类推。

用于SVC的H2BR算法

一般而言，当吞吐量波动时，ABR算法必须调整下一个片段的质量以适应这些变化，从而导致差距出现。这种现象可能对用户的QoE产生负面影响。因此，建议通过下载质量低于相邻片段的额外层来填补这些差距。需要注意的是，这种策略需要在客户端实现，因此额外层必须与下一个片段的层同时下载。例如，如图3所示，缓冲区中有四个片段，如果传输速率足够高以传输第4个片段的下一个BL，并且还能够容纳另一个额外层，那么客户端应该同时下载这两个层以解决差距问题。

在本文中，建议将H2BR与修改后的AGG方法结合起来，用于可扩展视频流传输。在客户端确定下一个片段的层数后，将这些层的总比特率与预估吞吐量进行比较。如果总比特率小于预估吞吐量并且当前缓冲区大于阈值 B^t，则调用H2BR扫描缓冲区并检测表示质量差距的片段。当检测到差距时，如果满足以下条件，则下载较低质量片段的下一个EL（称为额外层）：(1) 分配给额外层传输的吞吐量 T^a 小于预估吞吐量T^e，以便可以同时下载下一层；(2) 下载下一个片段和额外层后的预估缓冲区 B^e 必须大于某个阈值Θ，以避免停顿。这些条件定义为：

其中，R^A 和 𝜏 分别表示附加层的比特率和片段持续时间，T^A 是在播放之前下载该附加层的可用时间。设 t^p表示附加层的播放时间， t^curr表示当前播放片段的时间。t^a 通过公式 2 进行计算。

如果存在多个满足条件（1）的间隙，则我们将优先考虑播放时间最早的间隙。之后，分别发送两个独立的请求，一个是下一个片段的基础层，另一个是附加层。为了确保附加层有足够的吞吐量 𝑇 A，可以为每个请求分配一个优先权重，计算方法如下：

其中，P^A 和 P^N 分别是附加层和下一个片段基础层的优先权重。由于该技术最初是针对HTTP/2提出的，根据RFC 7540 ， P^A 和 P^N 必须是1到256之间的整数。在附加下载期间，H2BR会监视即时缓冲区状态和附加层播放之前的剩余时间。如果检测到当前缓冲区小于一定的阈值 B^ʅ或剩余下载附加层的时间小于预定义的阈值t^ʅ，附加层将被客户端终止。为避免频繁终止，B^ʅ和t^ʅ都应该较小，但B^ʅ必须足够高，以最小化播放停顿的风险并快速启动新的附加下载。这些阈值的示例设置在第4节中给出。

这种H2BR方法已在HTTP/2中实施。为了评估QUIC对该方法的影响，本文使用HTTP/3作为应用层，它建立在QUIC之上，支持流优先级和流终止。

实验配置

测试平台包括一台运行Ubuntu 18.04 LTS的服务器和一台作为客户端的虚拟机，运行Ubuntu 14.04 LTS。两台机器都基于LSQUIC 1版本2.14.2实现了QUIC和HTTP/3，以及nghttp2 2库实现了HTTP/2。LSQUIC中的有效优先级值与HTTP/2中的相同。为了使用流优先级功能，在LSQUIC中，客户端和服务器之间进行协商的是QUIC的Q043版本。我们使用一个4G网络数据来使用DummyNet模拟网络条件；该跟踪中的平均带宽为18,778 kbit/s，最大带宽为64,143 kbit/s。

服务器存储了SHVC视频RaceNight，视频长度为12秒，编码为一个BL和三个EL层。片段的持续时间为1秒，视频会重复播放，直到播放时间达到200秒。由于ABR算法和H2BR只考虑片段的比特率而不考虑视频内容，因此重复的短视频可以提供与具有相同比特率设置的更长视频相当的结果。使用Scalable HEVC（SHVC）测试模型7.0（SHM 7.0）将视频的每个片段编码为四个层。从BL到顶部EL，分辨率分别为720p、1080p、4K和4K，量化参数设置为37、37、37和32，平均比特率分别为1082 kbit/s、924 kbit/s、18,939 kbit/s和18,464 kbit/s。第一个4K层用于空间可扩展性，第二个层用于质量（保真度）可扩展性。这种最小化的内容配置针对HD和UHD场景。对于HAS来说，更全面的比特率设置将在未来的工作中进行研究。

在客户端，实现了修改后的AGG（M-AGG）方法和Backfilling方法来流传输SHVC视频。这些方法与将MAGG与H2BR技术集成在一起的方法进行比较。以下将用H2BR和BF分别表示这种方法和Backfilling方法。

本文考虑了两个评估场景：（A）第一个场景侧重于HTTP/3在QUIC和HTTP/2之上处理存在数据包丢失的先行阻塞的能力，其中数据包丢失率设定在0%到5%的范围内, 缓冲区大小设置为20秒，以防止缓冲区饥饿现象。（B）第二个场景考虑了缓冲区大小对基于SHVC的视频流传输的影响，数据包丢失率设置为0%。使用了几个不同的缓冲区大小𝐵（5秒、10秒、15秒、20秒），分别对应5个、10个、15个和20个片段。

在实验中，当缓冲区大小为5、10、15和20个片段时，客户端开始视频播放时，缓冲区至少填充了3、6、10和15个片段。H2BR的所有其他参数设置如下： 𝐵^t= 𝐵/2，Θ = 𝐵/4，B^ʅ = 𝐵/4，t^ʅ = 0.1s。与其他实际仿真一样，DummyNet只能近似模拟真实系统的行为。这些近似主要是由于系统时钟的有限粒度和精度引起的。由于网络行为具有轻微的随机性，每个实验重复三次。

在本文中，考虑以下指标：(1)平均视频质量，即每个片段中的平均层数（1-4层）；(2)降级切换次数，由层数少于前一个片段的片段数量确定；(3)平均切换幅度，表示片段中层数的平均减少量；(4)停顿次数和停顿持续时间，分别是缓冲区耗尽的次数和总的缓冲区耗尽时间。需要注意的是，只考虑了降级切换，因为它们对用户体验的负面影响较大于升级切换。

结果分析

丢包率的影响

上图展示了在不同网络数据包丢失率下比较的ABR算法在HTTP/3和HTTP/2上的性能。在图a中，当没有数据包丢失时，每种ABR算法在HTTP/3和HTTP/2上的性能基本相同。然而，当数据包丢失率超过0%时，与使用相同ABR算法的HTTP/2相比，HTTP/3可以提供更高的平均视频质量。例如，当数据包丢失率为1%时，H2BR在HTTP/3上的平均视频质量为2.57，而在HTTP/2上为2.36。此外，当数据包丢失率从0%增加到5%时，HTTP/2的性能显著低于HTTP/3。例如，H2BR在数据包丢失率为0%时的平均视频质量下降了21.6%，从2.57降至2.58，而在HTTP/3上只下降了10.5%。对于BF在HTTP/2上的平均视频质量，数据包丢失率从0%下降到5%时，从2.53降至1.73（下降31.8%），而在HTTP/3上仅下降了17.1%，从2.52下降至2.08。这可以解释为何在数据包丢失率为0%时，HTTP/3和HTTP/2的平均吞吐量基本相同，在发生数据包丢失时，HTTP/2通过使用三个选择性确认（Selective ACKs）的范围通知最近成功的数据包，这导致恢复速度较慢。相反，HTTP/3的QUIC传输协议支持比TCP更多的确认范围，提供了更快的丢包恢复。这导致了更可靠的吞吐量测量，从而获得更高的视频质量。

对于图b中显示的质量切换情况，在数据包丢失率为0%时，HTTP/3和HTTP/2在每种ABR算法下经历的切换次数相似。然而，在发生数据包丢失时，当使用HTTP/3时，实施M-AGG或H2BR的客户端切换次数较少，而使用HTTP/3时，BF的切换次数较多于在HTTP/2上的情况。可以看到，当数据包丢失率为5%时，HTTP/3并不能帮助H2BR减少切换次数。这是因为在HTTP/3和HTTP/2中测得的吞吐量都很小，H2BR无法消除需要至少一个额外层的差距。图c报告了HTTP/3和HTTP/2的平均切换幅度之间的轻微差异

缓冲区大小的影响

上图比较了使用HTTP/2和HTTP/3以及不同缓冲区大小和0%数据包丢失率的三种方法的性能。HTTP/3和HTTP/2在比较的方法的性能方面没有明显差异。对于H2BR，HTTP/3对于我们提出的方法稍微提高了平均视频质量和切换次数。

在比较不同的ABR算法时，当使用HTTP/3进行流传输并且缓冲区至少为10秒时，我们提出的方法实现了最佳性能。此外，H2BR实现了最高的平均视频质量和最低的切换次数。虽然BF提供了相对较高的平均视频质量，但它同时遭受了最高的切换次数以及最高的平均切换幅度。这是因为当缓冲区未完全填满时，在下载高层（例如顶部EL）后，BF经常跳转到下载下个片段的BL。当缓冲区较小（例如5秒）时，H2BR在平均视频质量方面无法超越BF方法，因为下载额外层的时间较短。然而，H2BR在使用HTTP/3协议时提供了显著较少的切换次数，即10次，而BF为50次，M-AGG为17次，并保持了可接受的平均切换幅度。

总结

本文提出了一种在QUIC上进行SVC视频自适应流传输的高效方法。该方法结合了针对非可扩展视频编码格式引入的修改后的自适应逻辑和H2BR技术，该技术从缓冲区中获取存储的片段的附加增强层，以最大化平均视频质量并最小化质量切换。从实验结果中得出两个结论。首先，由于QUIC具有快速恢复和HOL阻塞消除的能力，它可以很好地支持并发流，在数据包丢失的情况下提供显著更好的性能。其次，所提出的方法不仅在非可扩展视频流传输中有效，而且在可扩展视频流传输中也取得了改进。然而，当缓冲区大小较小时，H2BR可能会给客户端带来负担，导致缓冲区饥饿。