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

苹果低延迟HLS的承诺是比标准HLS更低的延迟，并向后兼容非ll HLS意识的玩家. Mux视频服务的承诺是“视频，秒。." As you'll see in this tutorial, both companies hit their mark, 使用Mux的LL HLS非常容易实现，延迟为4-7秒, a bit higher than expected, 但与其他提供相同服务的公司一致.

According to the company's website, “Mux Video是一个API，使开发人员能够构建独特的直播和点播视频体验.该公司不提供GUI，但让它变得简单，你将在下面看到. 尽管Mux提供实时转码服务已经有一段时间了, 他们的LL HLS服务在撰写本文时仍处于测试阶段.

Technically, Mux is a cloud transcoding service; you create the live stream and deliver it to Mux, 该服务对视频进行转码，并提供一个URL，您可以使用它将流发送给目标观众. Creating the streams is a two-step process; first, you create the encoding instance, 然后，从实时编码器向实例交付单个流.

In this tutorial, I'll review this process, 测试我们生成的流的延迟, 并向您介绍一些有价值的百家乐软件，以使您熟悉LL HLS的当前性能范围. For the record, Mux changes $0.04/分钟用于编码完整的编码阶梯和$0.0012/minute for delivering the streams.

Let's jump right in.

开始与LL HLS和Mux视频

To create the live stream in Mux, 发出以下POST请求，该请求可直接从Mux获得 documentation (Figure 1). 您可以看到，将减少的延迟标记设置为true，从而启用低延迟HLS.

Figure 1. Here's the code that enables LL HLS.

直接从Mux网站启动服务, 将代码粘贴到Create a New Live Stream POST主体编辑器中，然后单击Run Request, which produces the API call (Figure 2). Obviously, 这只适用于如果我登录到我的帐户，因为代码是通用的，不以任何方式识别帐户.

Figure 2. Initiating the API call

Once the live stream starts, 您可以从Live Stream描述符中获得几个关键的数据片段 Figure 3. First, 它提供了RTMP选项和流键，以进入您的直播流编码器，以将流传输到Mux (Figure 4). 其次，它提供播放内容的播放id.

Figure 3. 有关如何将视频传送到Mux以及如何播放转码文件的信息

I used OBS Studio 27.1.3 for my tests, 加载了很久以前乔赛亚·韦弗的演唱会视频，视频中嵌入了时间编码来测量延迟. 为了将OBS连接到Mux，我将服务器地址和流密钥插入到流设置选项卡中，如图4所示.

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

Mux为输入流的编码参数提供高级指令, recommending the H.264主配置文件，1080p 30 fps视频配置为5 Mbps，关键帧间隔为2秒(Figure 5). OBS自动选择了非常快的预设，当然你可以升级到快速, 如果在足够快的计算机上编码，则为中等或更高, but I just used as is. 我还将调优设置为零延迟和x264选项，如图所示.

Figure 5. Setting the encoding parameters.

然后我开始在OBS中播放音乐会视频，按下流媒体按钮，我就开始运行了(Figure 6). 您可以在图3所示的直播流描述符字段的右侧看到正在播放的视频, 这张照片显然是在直播开始后拍的. 如果您研究图6的右下角，您会注意到CPU利用率为14.4%, 这是一个明确的信号，表明我本可以选择一个更高质量的预设, though not relevant for these tests.

Figure 6. OBS is sending the live stream to Mux.

Once you start the stream, Mux starts transcoding, 自动创建由Mux优化的编码阶梯. By design, Mux doesn't let you adjust or even see the specific encoding controls for the ladder; a plus if you favor simplicity over complexity, 但如果你是一个喜欢修补的编码专业人员，这是一个缺点.

Testing Latency and Playback

起床跑步再容易不过了. Now it was time to measure latency. I started at the THEOplayer LL HLS test page, which has several valuable features. 首先，该网站包括来自多个供应商的直播流，您可以在 Figure 7，因此您可以测试来自多个提供程序的延迟，下面将详细讨论.

Figure 7. THEOplayer ll - hl测试页面允许您测试来自多个提供商的延迟和性能.

Second, 该站点测量您提交用于播放的流的延迟，并允许您探索低延迟和流健壮性之间的权衡. You see this in Figure 8. 视频窗口右侧的当前统计信息显示了延迟和缓冲区大小, which for most services, including Mux, 平均在4到8秒之间. This is latency in default mode.

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

如果单击“托管固定延迟”下面的“启用”复选框, 您可以调整滑块显示的参数，并探索对延迟和流健壮性的影响. 本讨论中最重要的是目标延迟, 玩家将尝试通过减少视频缓冲来实现哪些目标. For the sake of completeness, Window控件设置延迟高于目标的容忍窗口, here .25 seconds. Seek设置容忍窗口，在此之后玩家将寻求达到目标延迟, 而Rate则设置玩家为达到目标延迟而进行的速度调整量. 这些是你可以在播放器中设置的控制，以调整到所需的延迟和响应，当这个延迟没有达到.

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

为了便于比较，禁用了Manage Fixed Latency后，Akamai的平均延迟约为7.在我280Mbps的连接上2秒，Wowza大约7秒，Synmedia大约6秒.9 seconds, Nimble Streamer around 5.5秒，罐装Mux流6左右.0 seconds, and Flussonic around 7.5 seconds. 我使用Mux服务生成的流大约是5.5 seconds without any adjustments. 唯一的异常是Broadpeak，它显示了1的延迟.在顶部屏幕中为4，但在底部图形中延迟超过4秒. 所有其他服务的数值和图表得分大致匹配, 所以我不知道该如何看待Broadpeak的结果.

Other LL HLS Solutions

我通过截图测试了其他玩家的延迟，其中包括OBS和玩家，并比较了时间代码. 为《百家乐软件》做过优化的玩家，比如 JW Player and HLS.js 平均在5到6秒之间，如 Figure 9 below.

Figure 9. 视频在左侧的程序窗口, in the player window on the right, 显示HLS的延迟不到6秒.js player.

Interestingly, the HLS.js demo webpage，它提供了大量有用的信息，显示延迟为3.634秒，你可以看到从底部开始的5行 Figure 10，而实际测量的延迟接近6秒. 看起来，要实现准确的延迟测量，您需要访问编码器和播放器，就像我们在本教程中所做的那样.

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

On the other hand, 没有为LL HLS进行优化的玩家, 像本地HLS播放Chrome扩展, showed latency as high as 26 seconds, 这证明了LL HLS在非LL HLS玩家上是向后兼容的, though at normal latency. 在运行iOS 15的iPhone 13 Pro上，由mux制作的流媒体在Safari中播放得非常完美.1.1、延迟仅超过6秒(Figure 11).

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

So, what did we learn? 从延迟的角度来看，Mux LL HLS解决方案具有竞争力, is exceptionally easy to use, and quite inexpensive. 虽然LL HLS似乎无法为真正的交互式应用程序提供足够短的延迟, 延迟当然足够低，可以匹配或击败电视上播放的大多数现场体育节目, and for other non-televised productions.

[编者注:本文首次发表于2022年。 Streaming Media Industry Sourcebook.]