原标题：How to Implement Low-Latency HLS (LL HLS) 原文链接：https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-to-Implement-Low-Latency-HLS-(LL-HLS)-151723.aspx 翻译整理：徐鋆
苹果公司的低延迟 HLS （LL HLS）的承诺是比标准 HLS 更低的延迟，并向后兼容非 LL HLS 的播放器。Mux 视频服务的承诺是“视频，在几秒钟内”。正如你将在本教程中所看到的，两家公司都达到了他们的目标，Mux 的 LL HLS 特别容易实现，延迟为 4-7 秒，比预期的要高一点，但与其他提供相同服务的公司一致。
根据该公司的网站，“Mux Video 是一个 API，使开发者能够建立独特的直播和点播视频体验”。该公司不提供 GUI，但使实验变得简单，你会在下面看到。虽然 Mux 已经提供实时转码服务有一段时间了，但在写这篇文章时，他们的 LL HLS 服务仍处于测试阶段。
从技术上讲，Mux 是一个云转码服务；你创建直播流并将其交付给 Mux，该服务对视频进行转码并提供一个 URL，你用来将流媒体交付给目标观众。创建流媒体是一个两步的过程；首先，创建编码实例，然后从你的直播编码器提供一个单一的流媒体到该实例。
在本教程中，我将回顾这个过程，测试我们制作的流的延迟，并介绍一些有价值的资源，让你熟悉 LL HLS 的当前性能包络。为了记录在案，Mux 对整个编码阶梯的编码费用为 0.04 美元/分钟，对流媒体的传输费用为 0.0012 美元/分钟。
让我们直接开始吧。
目录
- 开始使用 LL HLS 和 Mux 视频
- 测试延迟和播放
- 其他 LL HLS 解决方案
- 参考文献
开始使用 LL HLS 和 Mux 视频
为了在 Mux 中创建直播流，做以下 POST 请求，这可以直接从 Mux 文档[1]中获得（图 1）。你可以看到，降低延迟的标签被设置为“true”，这使得低延迟的 HLS 成为可能。
图 1 启用 LL HLS 的代码
要直接从 Mux 网站上启动服务，你可以将代码粘贴到创建新的实时流 POST 主体编辑器中，然后点击运行请求，这就产生了 API 调用（图 2）。显然，这只有在登录了账户时才有效，因为代码是通用的，没有以任何方式识别账户。
图 2 初始化 API 请求
一旦直播流开始，可以从图 3 所示的直播流描述符中得到几个关键数据。首先，它提供了 RTMP 选项和流密钥，以输入你的直播流编码器，将流传送到 Mux（图 4）。第二，它提供了用于播放内容的播放 ID。
图 3 如何将视频交付给 Mux 以及如何播放转码后的文件的信息
我使用 OBS Studio 27.1.3 进行测试，加载了一段 Josiah Weaver 的音乐会视频，其中有嵌入的时间码来测量延迟。为了将 OBS 连接到 Mux，我将服务器地址和流密钥插入流设置标签，如图 4 所示。
图 4 在 OBS 中插入 Mux 地址和流密钥
Mux 为输入流的编码参数提供了高层指示，推荐 H.264 main 配置文件，1080p 30 fps 视频配置为 5 Mbps，关键帧间隔为 2 秒（图 5）。OBS 自动选择了 veryfast preset，当然，如果你在一台足够快的计算机上进行编码，你可以升级到 fast, medium 或更高的 preset，但我只是按原样使用。我还将 Tune 选项保持在 zerolatency ，x264 相关选项如图所示。
图 5 设置编码参数
然后我开始在 OBS 中播放音乐会视频，并按下流媒体按钮，开始运行（图 6）。你可以在图 3 所示的直播流描述符字段中看到右侧正在播放的视频，这显然是在启动直播流后拍摄的。如果你研究一下图 6 的右下方，你会注意到 CPU 利用率为 14.4%，这肯定表明我可以选择一个更高的质量 preset，尽管与这些测试无关。
图 6 OBS 正在向 Mux 发送直播流
一旦你开始流，Mux 就开始转码，自动创建一个由 Mux 优化的编码阶梯。根据设计，Mux 不会让你调整，甚至不会让你看到阶梯的具体编码控制；如果你喜欢简单而不是复杂，这是一个优点，但如果你是一个喜欢修补的编码专家，这是一个缺点。
测试延迟和播放
启动和运行再容易不过了。现在是测量延迟的时候了。我从 THEOplayer LL HLS 测试页面[2]开始，它有几个有价值的功能。首先，正如你在图 7 中看到的，该网站包括来自多个供应商的实时流，因此你可以测试来自多个供应商的延迟，下面将详细讨论。
图 7 THEOplayer LL-HHL 测试页面可以让你测试多个供应商的延迟和性能
第二，该网站测量你提交的流的延迟，让你探索低延迟和流的稳健性之间的权衡。你可以在图 8 中看到这一点。视频窗口右侧的当前统计数据显示了延迟和缓冲区大小，对于大多数服务，包括 Mux，平均在 4 到 8 秒之间。这是默认模式下的延时。
图 8 探讨缓冲区大小和延迟之间的关系
如果你勾选“Managed Fixed Latency”下面的“Enabled”，就可以用滑块调整显示的参数，并探索对延迟和流健壮性的影响。对这次讨论最重要的是目标延迟，播放器将试图通过减少视频缓冲区来实现。为了完整起见，Window 控制设置了超过目标延迟的容忍窗口，这里是 0.25 秒。Seek 选项设置容忍窗口，之后播放器将寻求实现目标延迟，而 Rate 选项设置播放器为实现目标延迟所做的速度调整量。这些是你可以在播放器中设置的控制，以调整到所需的延迟，以及当这个延迟没有达到时的反应。
在图 8 中，目标延迟被设定为 1.5 秒，你看到实际延迟是 3.6 秒。然而，通过跟踪播放器下面的图表中的缓冲区和延迟水平，你可以看到，当延迟在 2 秒左右时，缓冲区跌至谷底，导致短暂的播放停止。这说明了延迟和稳健性之间的关系；也就是说，较低的延迟意味着较低的稳健性，反之亦然。
为了便于比较，在禁用 Manage Fixed Latency 的情况下，在我的 280Mbps 连接上，Akamai 的延迟平均约为 7.2 秒，Wowza 约为 7 秒，Synmedia 约为 6.9 秒，Nimble Streamer 约为 5.5 秒，canned Mux 流约为 6.0 秒，Flussonic 约为 7.5 秒。我使用 Mux 服务制作的数据流在没有任何调整的情况下大约是 5.5 秒。唯一不正常的是 Broadpeak，它在顶部屏幕上显示的延迟是 1.4 秒，但在底部图表中的延迟超过 4 秒。所有其他服务的数字和图表分数大致相符，所以我不知道该如何看待 Broadpeak 的结果。
其他 LL HLS 解决方案
我通过拍摄包括 OBS 和播放器的截图并比较时间码来测试其他播放器的延迟。为 LL HLS 进行了优化的播放器，如 JW Player[3] 和 HLS.js[4]，平均在 5 到 6 秒之间，如下图 9 所示。
图 9 左边的程序窗口中的视频，右边的播放器窗口中的视频，显示 HLS.js 播放器的延迟略低于 6 秒
有趣的是，HLS.js demo 网页提供了大量有用的信息，显示延迟为 3.634 秒，你可以在图 10 中从底部五行看到，而实际测量的延迟接近 6 秒。看来，为了实现准确的延迟测量，你需要同时访问编码器和播放器，就像我们在这个教程中所做的那样。
图 10 HLS.js demo 页面提供了很多数据，但它的延迟测量似乎不正确
另一方面，没有针对 LL HLS 进行优化的播放器，如 Native HLS Playback Chrome 扩展，显示延迟高达 26 秒，这倾向于证明 LL HLS 在非 LL HLS 播放器上是向后兼容的，尽管延迟是正常 HLS 的量级。Mux 制作的数据流在运行 iOS 15.1.1 的 iPhone 13 Pro 的 Safari 浏览器中完美播放，延迟刚刚超过 6 秒（图 11）。
图 11 在运行 iOS 15 的 iPhone 上，延迟时间刚刚超过 6 秒
那么，我们学到了什么？从延迟的角度来看，Mux LL HLS 解决方案很有竞争力，特别容易使用，而且价格相当便宜。虽然 LL HLS 似乎不能为真正的交互式应用提供足够短的延迟，但其延迟肯定低到足以匹配或击败电视上播放的大多数现场体育节目，以及其他非广播节目。
参考文献
[1] https://docs.mux.com/guides/video/reduce-live-stream-latency#is-low-latency-hls-different-from-standard-latency-hls [2] https://www.theoplayer.com/ll-hls-test-page [3] https://developer-tools.jwplayer.com/stream-tester [4] https://hls-js.netlify.app/demo/ [5] https://github.com/video-dev/hls.js
