来源：Global Video Tech: New York 主讲人：Bo Zhang, Brightcove 内容整理：尹文沛 减少端到端流传输延迟对于基于 HTTP 的实时视频流传输至关重要。目前该领域有两种技术：低延迟 HTTP 实时流媒体 (LL-HLS) 和基于 HTTP 的低延迟动态自适应流媒体 (LL-DASH)。许多播放器支持 LL-HLS 和/或 LL-DASH 协议，包括 Apple 的 AVPlayer、Shaka 播放器、HLS.js Dash.js 等。本文致力于分析低延迟播放器和流媒体协议的性能。该评估基于一系列实时流媒体实验，使用相同的视频内容、编码器、编码配置文件和网络条件重复进行，并使用真实网络的痕迹进行模拟。我们的实验捕获并报告了几个性能指标，例如平均流比特率、下载的媒体数据量、流延迟以及缓冲和流切换统计数据。这些结果随后用于描述观察到的 LL-HLS 和基于 LL-DASH 的播放器的性能差异。
简介
在未知或不断变化的网络条件下的操作一直是自适应比特率流媒体系统自 1990 年代诞生以来一直试图解决的最基本挑战之一。这个挑战今天仍然存在，尽管在某种程度上简化了设置，允许使用基于 HTTP 的自适应流 (HAS) 架构。在这样的架构中，网络适配逻辑驻留在流媒体客户端中，有效地驱动媒体流片段的选择和加载。在过去的十年中，已经提出了许多先进的方法来设计流选择算法。这包括基于吞吐量的方法、基于缓冲区级别的启发式、控制理论方法以及机器学习算法。
然而，不同网络自适应算法的比较提出了技术挑战。一些提议的算法仅在 Web 浏览器中基于带宽节流工具的模拟环境中进行了评估。此类工具只能在应用层控制视频播放器的下载带宽，无法准确模拟移动网络中存在的高度波动的网络带宽变化或丢包统计。
为了确保对不同播放器进行更准确和公平的评估，在本文中，我们引入了一个自定义评估框架，结合了 Mahimahi 网络模拟器。我们的框架通过在所有播放会话中重放相同的网络跟踪来保证不同播放器的公平比较。这允许在相同条件下并排比较多个播放器。Mahimahi 网络模拟器可以使用从不同移动运营商记录的物理网络轨迹来准确模拟移动网络链接。具体而言，在本研究中，我们将使用来自 TMobile 和 Verizon 4G LTE 的网络轨迹。
考虑到低延迟流是逐块传输的，并且客户端可用的缓冲区要小得多，因此估计网络带宽和做出流自适应决策变得更具挑战性。低延迟自适应算法的其他变体可以在 LL-HLS 流播放器中找到，例如 HLS.js、Shaka 播放器 和 Apple 的 AVPlayer。
本文致力于在通用评估框架中评估低延迟 DASH 和 HLS 播放器及其各自的 ABR 自适应算法，以确保准确和公平的比较。在第 2 节中，我们将描述评估设置。在第 3 节中，我们将介绍和讨论测量结果。
实验设置
流媒体工具链
我们用于 LL-HLS 和 LL-DASH 流的工具链的总体图分别如图 1 和图 2 所示。为了生成 LL-HLS 流，我们使用了 Apple 的 HLS 参考工具和 FFmpeg。为了生成 LL-DASH 流，我们使用了 OBS studio、FFmpeg 和 node-gpacdash。LL-HLS 流由 NGINX 网络服务器动态提供。LL-DASH 流由 node-gpac-dash 动态提供。
图 1 用于测试 LL-HLS 播放器的工具链
图 2 用于测试 LL-DASH 播放器的工具链
如图 1 和图 2 所示，输入视频流被发送到低延迟打包器（用于 LLHLS 的 media stream segmenter 和用于 LL-DASH 的 FFmpeg）。低延迟打包器的输出是分块的视频片段和清单文件，通知播放器如何在低延迟模式下使用流。接下来，输出流文件由低延迟媒体服务器（用于 LL-HLS 的 lowLatencyHLS.php，用于 LL-DASH 的 node-gpac-dash）以分块的方式提供给播放器。
在播放器端，网页播放器运行在 Chrome 浏览器上，iOS 原生播放器（HLS）运行在 iOS 上的 AVPlayer 框架上。Chrome 浏览器和 AVPlayer 在 Mahimahi 容器内运行，并通过模拟的虚拟网络接口连接到媒体服务器。
测试内容和编码参数
作为测试视频序列，我们使用了 1080p 版本的 Big Buck Bunny 视频。该序列被循环以实现连续测试。对于流媒体，随后生成了 3 个实时转码变体流，其参数列于表 1。
表 1 编码参数
为了最大限度地减少编码比特率与其声明目标的波动，使用了恒定比特率 (CBR) 编码模式。为了最大限度地减少编码延迟，使用了在基线配置文件中运行的 H.264 编码器。段长度和片段持续时间分别设置为 4 秒和 1 秒，与 Apple 的 LL-HLS 流媒体工具中使用的默认值相匹配。相同的编码参数已用于生成 LL-DASH 和 LL-HLS 流。
我们用来测试每个播放器在每个网络下的表现的总会话持续时间为 10 分钟。给定选定的块和片段持续时间，这允许每个 session 下载大约 600 个块或等效的 150 个段。
流播放器
我们评估了 6 种低延迟流媒体播放器的实现。对于 LL-HLS，我们使用了 HLS.js 、Shaka player 和 Apple 的 AVPlayer。对于 LL-DASH，我们使用 Dash.js 和三种不同的低延迟 ABR 算法：Dash.js 原创、Dash.js 和 LoL 算法和 Dash.js 和 L2All 算法。我们已经为所有播放器实现了简单的测试应用程序。这些应用程序是使用 2020 年 12 月发布的最新播放器 SDK 版本构建的。
性能度量
指示实时流传输延迟、播放速度和重新缓冲事件的指标已在视频播放器应用程序中进行检测。其他指标（例如流比特率、视频分辨率和下载的媒体数据）来自流媒体服务器的访问日志。所有收集到的指标的处理都是离线完成的。
从本质上讲，在任何时间点，我们都会从流会话开始（等式 1）开始计算经过的演示时间和经过的挂钟时间之间的差异：
其中 PL 表示实时演示延迟，WC 和 PT 分别表示当前挂钟时间和当前演示时间。WCA 和 PTA 分别代表开始挂钟时间和开始演示时间。对于 LL-DASH，上述值是从嵌入在 MPD 文件中的 ProducerReferenceTime 元素和 W3C HTML5 视频 currentTime API 和/或 DASH MPD 文件中获得的。对于 LL-HLS，这些值源自 HLS m3u8 文件和 currentTime API。
重新缓冲事件的数量和播放器的播放速度分别通过使用等待事件 API 和回放速率 API 获得。
播放速度变化计算为所有测量的播放速度相对于原始速度（等于 1）的欧几里德距离：
此公式中使用的参数 N 表示会话期间进行的播放速度测量次数。
所有其他指标（包括流比特率、视频分辨率、下载的媒体数据、比特率切换次数）均来自服务器日志。在我们的测试系统中收集的完整指标列表总结在表 2 中。
表 2 收集的性能指标列表
我们使用 Mahimahi 网络模拟器在网络接口级别模拟各种网络条件。Mahimahi 本质上是一个 Linux 容器，可以在其中运行应用程序。Mahimahi 内部的应用程序通过虚拟网络接口连接到外部世界，该接口根据运行的下行链路和上行链路跟踪发送和接收字节。这样，网络接口的容量就受到运行轨迹的限制。我们使用了从真实世界移动网络中记录的轨迹。当我们在 Mahimahi 中运行测试播放器时，播放器下载速度受到虚拟界面容量的限制。与在 Web 浏览器中使用带宽限制功能不同，Mahimahi 通过在网络接口级别使用真实世界的跟踪和限制带宽来提供更可靠的网络模拟。此外，所有测试会话都会重放相同的网络跟踪。这允许对不同的播放器进行公平的比较。
我们分别使用来自 T-Mobile 和 Verizon 的两个 4G-LTE 网络轨迹对测试参与者进行了评估。我们在图 3 中提供了这些轨迹的可视化。在表 3 中，我们进一步列出了与它们相关的基本统计数据。我们注意到，这些网络轨迹非常具有挑战性，可以捕获实际中可能发生的移动切换和其他形式的损伤情况。
表 3 网络轨迹的统计特性
图 3 实验中使用的网络带宽跟踪
实验结果
Verizon 4G LTE 网络的结果
首先，我们回顾了使用 Verizon 4G LTE 网络轨迹获得的结果。表 4 提供了汇总指标。LL-HLS 播放器实现的比特率和延迟变化的动态分别如图 4 和图 5 所示。
表 4 播放器指标摘要 – Verizon 4G LTE
表 5 播放器指标总结——T-Mobile 4G LTE
图 4 比特率随时间变化 – LL-HLS / Verizon 4G
图 5 实时延迟 - LL-HLS / Verizon 4G
根据图 5，我们注意到 Shaka 播放器的延迟在整个会话中几乎持平，平均值为 7.28 秒。这高于 HLS.js 实现的 4.32 秒，但明显低于 AVPlayer 实现的 15.96 秒。尽管 HLS.js 的平均延迟较低，但它在整个会话中的行为并不稳定：它变化非常显着，在会话中间产生大量延迟峰值。在我们看来，应该避免这种峰值。
当延迟发生变化时，播放器必须比流的原生速度更快或更慢才能保持在流的实时边缘。表 4 中报告的播放速度变化数字证明了这一点。播放速度变化值越低，表示 QoE 越好。
根据图 5，我们还注意到 AVPlayer 能够在前 260 秒内以低延迟（约 4.8 秒）进行流式传输。当第一个主要带宽波动发生时（即图 3 中的时间间隔 [250 - 340]），AVPlayer 遇到缓冲区变空的情况，并且在重新缓冲和恢复播放后无法保持低延迟。延迟上升到 12 秒，然后到 17 秒直到结束。
在流比特率方面（参见图 4），我们注意到 Shaka 播放器在 10 分钟的会话中达到了最高的平均值 (1228 kbps)，其次是 AVPlayer (1136 kbps) 和 HLS.js (849 kbps)。从图 4 中还可以看出，Shaka 播放器大部分时间都能够以最高比特率进行流式传输，而 HLS.js 经常犹豫是否切换到更高的比特率，或者当其他播放器仍然坚持使用更高的比特率时它会切换到较低的比特率 . 这在时间间隔 [350 – 470] 中尤为明显。一般来说，更高的平均比特率应该会给观众带来更好的 QoE。
接下来，我们注意到 Shaka 播放器的比特率切换次数最少，10 分钟内只有两次。AVPlayer 切换了 130 次，其中大部分发生在时间间隔 [470 - 570] 内。在此期间，可用带宽不仅很低，而且波动很大（图 3）。作为对动态网络条件的反应，AVPlayer 通过为它下载的几乎每个片段切换比特率来快速适应。虽然 AVPlayer 在可用带宽允许的情况下迅速切换到更高的比特率，但当带宽下降时，它被迫切换回较低的比特率。通常，过度频繁的切换可能会损害 QoE。
另一个重要的 QoE 因素是缓冲区欠载的数量以及随之而来的重新缓冲事件的数量。AVPlayer 记录的重新缓冲事件最少，这是因为它的平均实时延迟（15.96 秒）远高于其他两个。更高的延迟意味着更多的缓冲和更高的带宽波动弹性。HLS.js 和 Shaka 播放器更接近流的实时边缘，因此，它们比 AVPlayer 更容易重新缓冲（HLS.js 为 36 次，Shaka 播放器为 12 次）。在这三者中，Shaka 播放器似乎在延迟和重新缓冲之间取得了更好的平衡。
最后，我们看看播放器在 10 分钟的会话中下载的数据量。Shaka 播放器下载了 587 个媒体对象，它们都是视频块，这意味着 Shaka 播放器在整个会话期间保持低延迟。由于应该在 10 分钟内下载 600 个块，因此 Shaka 跳过了 13 个块。AVPlayer 下载了 669 个媒体对象，包括 611 个块和 58 个整段。当 AVPlayer 无法在实时边缘下载部分块时，会下载整个片段，并回退到下载较早的整个片段。HLS.js 下载了 662 个块和 11 个整段。与 Shaka 播放器不同，AVPlayer 和 HLS.js 下载了 600 多个媒体对象。以字节为单位的下载数据方面，Shaka 下载了 90.16 MB，超过 HLS.js（85.36 MB），因为它的平均流比特率更高，低于 AVPlayer（98.52 MB），因为下载的媒体对象更少。
接下来，我们将注意力转移到 LL-DASH 播放器上。这些播放器实现的比特率和延迟变化的动态分别如图 6 和图 7 所示。
图 6 比特率随时间变化 – LL-DASH / Verizon 4G
图 7 实时延迟 - LL-DASH / Verizon 4G
从表 4 和图 6 中可以看出，原始 Dash.js 播放器实现了比 LoL (595 kbps) 和 L2ALL (1073 kbps) 变体更高的流比特率 (1165 kbps)。LoL 的比特率切换（29 次）明显多于 Dash.js（6 次）和 L2ALL（3 次）。LoL 实现了最低的平均比特率和比特率切换次数。然而，从图 7 中可以看出，LoL 还能够实现比 Dash.js（3.71 秒）和 L2ALL（3.9 秒）更低的平均延迟（3.2 秒）。LoL 播放器重新缓冲了 79 次，高于 L2ALL（56 次）和原始 Dash.js（5 次）。
原始 Dash.js 的播放速度变化也最低（0.19）。下载数据方面，3 个 LL-DASH 播放器共下载了约 150 个对象，均为整段。这是因为 LL-DASH 播放器依赖流媒体服务器使用 HTTP/1.1 分块传输编码逐块推送段，而不是像 LL-HLS 播放器那样请求单个块。换句话说，LLDASH 播放器只请求整个片段。最后，我们观察到所有 LL-DASH 播放器下载的片段数量几乎相同，下载的数据总量与这些播放器使用的平均比特率成正比。
T-Mobile 4G LTE 网络的结果
我们接下来回顾通过使用 T-Mobile 4G LTE 网络轨迹获得的结果。表 5 提供了汇总指标。LL-HLS 播放器实现的比特率和延迟变化的动态分别如图 8 和图 9 所示。
图 8 比特率随时间变化 – LL-HLS / T-Mobile 4G
图 9 随着时间的推移实时延迟 – LL-HLS / T-Mobile 4G
根据表 5 和图 8，我们注意到 Shaka 播放器和 AVPlayer 实现了比 HLS.js 更高的平均比特率。这可以在图 8 中的多个间隔中观察到，其中 HLS.js 似乎在努力选择正确的比特率，而其他播放器能够以更高的比特率播放。
基于图 9，我们还注意到 HLS.js 和 Shaka 播放器比 AVPlayer 实现了更低的延迟。AVPlayer 的延迟线在超过一半的会话中较低且平坦，但在接近结束时上升。就像使用 Verizon 跟踪时一样，HLS.js 在整个会话期间具有可变延迟。与其他两个播放器相比，Shaka 播放器具有更低且更稳定的延迟（平均为 7.78 秒）。
我们还注意到，HLS.js 在会话期间下载的媒体对象 (965) 比其他两个播放器多得多，而且在使用 Verizon 跟踪时也比它本身多。这可能是由于它在 T-Mobile 网络中经历了更多的重新缓冲事件和比特率切换。由于下载了更多媒体对象，HLS.js 也下载了更多字节（155.54 MB）。
在重新缓冲和比特率切换的次数方面，Shaka 播放器再次经历了更少的重新缓冲事件（18 次）和最少的切换（仅 8 次）。最后，HLS.js 由于其高度可变的延迟而具有很大的播放速度变化值。多次观察到 HLS.js 必须以 1.5 倍的速度播放才能赶上实时边缘。
最后，我们看看 LL-DASH 播放器的行为。这些播放器实现的比特率和延迟变化的动态分别如图 10 和图 11 所示。
图 10 比特率随时间变化 – LL-DASH / T-Mobile 4G
图 11 随着时间的推移实时延迟 – LL-DASH / T-Mobile 4G
根据表 5 和图 10，我们注意到原始 Dash.js 和 L2ALL 能够提取以比 LoL 播放器高得多的比特率编码的内容：分别为 1224.83 kbps 和 1250.83 kbps 与 537.21 kbps。LoL 播放器在大部分会话中使用最低比特率，而其他两名播放器使用最高比特率。
在媒体下载量方面，三款播放器都收到了大约150个整段。最初的 Dash.js 和 L2ALL 下载了更多的字节，以获得更高的平均比特率。
在重新缓冲事件和比特率切换的数量方面，原始 Dash.js 在三者中表现最好。它具有最少数量的重新缓冲事件（仅一次）和很少的比特率切换（仅 4 次）。最后，原始 Dash.js 的播放速度变化最小 (0.23)，低于 LoL (1.62) 和 L2Aall (0.42)。
总的来说，我们观察到原始 Dash.js 在三个播放器中表现最好。尽管 L2All 在比特率、延迟和比特率切换频率方面的表现稍好一些，但它也经历了更多的重新缓冲事件。
