如何实现低延迟HLS (LL HLS)

The promise of Apple's Low Latency HLS is lower latency than st和ard HLS with backwards compatibility with non-LL HLS aware players. Mux视频服务的承诺是“视频，秒。.正如您将在本教程中看到的, 两家公司都达到了目标, with Mux's LL HLS exceptionally easy to implement with a latency of 4-7 seconds, 比预期的要高一些, 但与其他提供相同服务的公司一致.

根据该公司的网站, "Mux Video is an API that enables developers to build unique live 和 on-dem和 video experiences." The company doesn't offer a GUI but makes it simple to experiment as you'll see 下面. 尽管Mux提供实时转码服务已经有一段时间了, 他们的LL HLS服务在撰写本文时仍处于测试阶段.

从技术上讲, Mux is a cloud transcoding service; you create the live stream 和 deliver it to Mux, 和 the service transcodes the video 和 provides a URL you use to deliver the streams to your target viewers. Creating the streams is a two-step process; first, 您创建了编码实例, 然后，从实时编码器向实例交付单个流.

在本教程中, 我将回顾这个过程, 测试我们生成的流的延迟, 和 introduce you to some valuable resources for familiarizing yourself with the current performance envelope for LL HLS. 根据记录，Mux改变了0美元.04/分钟用于编码完整的编码阶梯和$0.0012/分钟，用于传输流.

让我们开始吧.

开始与LL HLS和Mux视频

在Mux中创建直播流, 发出以下POST请求，该请求可直接从Mux获得文档 (图1). You see that the reduced latency tag is set to true, which enables low-latency HLS.

图1. 下面是启用LL HLS的代码.

直接从Mux网站启动服务, you paste the code into the Create a New Live Stream POST body editor 和 click Run Request, 生成API调用(图2). 很明显, this only works if I'm logged into my account since the code is generic 和 doesn't identify the account in any way.

图2. 初始化API调用

一旦直播开始, you get several critical pieces of data from the Live Stream descriptor shown in 图3. 第一个, it provides the RTMP options 和 stream key to enter into your live streaming encoder to deliver the stream to Mux (图4). 其次，它提供播放内容的播放id.

图3. Information about how to deliver your video to Mux 和 how to play the transcoded files

我用的是OBS Studio 27.1.3次测试, loading in a Josiah Weaver concert video from way back that had embedded time codes to measure latency. To connect OBS to Mux I plugged the server address 和 stream key into the Stream Settings tab as shown in 图4.

图4. 插入Mux地址和流键到OBS

Mux provides high-level instructions for the encoding parameters for the input stream, 推荐H.264 main profile with 1080p 30 fps video configured at 5 Mbps with a keyframe interval of 2-seconds (图5). OBS automatically selected the veryfast preset which of course you can upgrade to fast, 如果在足够快的计算机上编码，则为中等或更高, 但我只是按原样使用. 我还将调优设置为零延迟和x264选项，如图所示.

图5. 设置编码参数.

Then I started the concert video playing in OBS 和 pressed the Streaming Button 和 I was up 和 running (图6). You can see the video playing on the right in the live stream descriptor field shown in 图3, 这张照片显然是在直播开始后拍的. If you study the bottom right of 图6, you'll note the CPU utilization was 14.4%, 这是一个明确的信号，表明我本可以选择一个更高质量的预设, 虽然与这些测试无关.

图6. OBS正在向Mux发送直播.

一旦你开始流, Mux开始转码, 自动创建由Mux优化的编码阶梯. 通过设计, Mux doesn't let you adjust or even see the specific encoding controls for the ladder; a plus if you favor simplicity over complexity, 但如果你是一个喜欢修补的编码专业人员，这是一个缺点.

测试延迟和回放

起床跑步再容易不过了. 现在是测量延迟的时候了. 我从 THEOplayer LL HLS测试页面，它有几个有价值的功能. 首先，该网站包括来自多个供应商的直播流，您可以在图7, so you can test the latency from multiple providers as discussed in more detail 下面.

图7. The THEOplayer LL-HHL test page lets you test latency 和 performance from multiple providers.

第二个, the site measures the latency of the streams that you submit for playback 和 lets you explore the tradeoff between low latency 和 stream robustness. 你可以在图8. The current statistics to the right of the video window show the latency 和 buffer size, 对于大多数服务来说, 包括Mux, 平均在4到8秒之间. 这是默认模式下的延迟.

图8. 探索缓冲区大小和延迟之间的关系

如果单击“托管固定延迟”下面的“启用”复选框, you can adjust the parameters shown with sliders 和 explore the impact on latency 和 stream robustness. 本讨论中最重要的是目标延迟, 玩家将尝试通过减少视频缓冲来实现哪些目标. 为了完整起见, Window控件设置延迟高于目标的容忍窗口, 在这里 .25秒. Seek sets the tolerance window after which the player will seek to achieve the target latency, while Rate sets the amount of speed adjustment that the player will make to achieve the targeted latency. These are the controls you can set in the player to tune to the desired latency 和 response when this latency isn't achieved.

在图8中，目标延迟时间设置为1.5秒，实际延迟是3.6秒. 然而, 通过追踪玩家下方图表中的缓冲和延迟水平, 您可以看到，当延迟大约为2秒时，缓冲区达到了最低点, 导致短暂的播放停止. This illustrates the relationship between latency 和 robustness; that is, 较低的延迟意味着较低的健壮性，反之亦然.

For the sake of comparison, with Manage Fixed Latency disabled, Akamai's latency averaged around 7.2 seconds on my 280Mbps connection, with Wowza around 7 seconds, Synmedia around 6.9秒，敏捷流光大约5秒.5秒，罐装Mux流6左右.0秒，冲音在7秒左右.5秒. 我使用Mux服务生成的流大约是5.5秒，没有任何调整. 唯一的异常是Broadpeak，它显示了1的延迟.在顶部屏幕中为4，但在底部图形中延迟超过4秒. 所有其他服务的数值和图表得分大致匹配, 所以我不知道该如何看待Broadpeak的结果.

其他LL HLS解决方案

I tested latency in other players by taking a screenshot that included both OBS 和 the player 和 comparing the time codes. 为《百家乐app下载》做过优化的玩家，比如 JW球员和 HLS.js 平均在5到6秒之间，如图9 下面.

图9. 视频在左侧的程序窗口, 在右侧的玩家窗口中, 显示HLS的延迟不到6秒.js的球员.

有趣的是，HLS.js演示网页，它提供了大量有用的信息，显示延迟为3.634秒，你可以看到从底部开始的5行 图10，而实际测量的延迟接近6秒. It appears that to achieve accurate latency measurements you need access to both the encoder 和 player as we did for this tutorial.

图10. 的HLS.Js的演示页面提供了大量数据，但其延迟度量似乎不正确.

另一方面, 没有为LL HLS进行优化的玩家, 像本地HLS播放Chrome扩展, 显示延迟高达26秒, 这证明了LL HLS在非LL HLS玩家上是向后兼容的, 虽然在正常的潜伏期. The Mux-produced stream played perfectly in Safari on an iPhone 13 Pro running iOS 15.1.1、延迟仅超过6秒(图11).

图11. 运行iOS 15的iPhone的延迟仅为6秒多一点.

那么，我们学到了什么? 从延迟的角度来看，Mux LL HLS解决方案具有竞争力, 是否特别容易使用, 而且很便宜. While LL HLS doesn't appear capable of providing short enough latency for truly interactive applications, the latency is certainly low enough to match or beat most live sports productions shown on TV, 以及其他非电视制作.

[编者注:本文首次发表于2022年。流媒体行业资料手册.]