如何实现低延迟HLS （LL HLS）

苹果低延迟HLS的承诺是比标准HLS更低的延迟，并向后兼容非ll HLS意识的玩家. Mux视频服务的承诺是“视频，秒。.正如您将在本教程中看到的, 两家公司都达到了目标, 使用Mux的LL HLS非常容易实现，延迟为4-7秒, 比预期的要高一些, 但与其他提供相同服务的公司一致.

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

从技术上讲, 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, 您创建了编码实例, 然后，从实时编码器向实例交付单个流.

在本教程中, 我将回顾这个过程, 测试我们生成的流的延迟, 并向您介绍一些有价值的百家乐软件，以使您熟悉LL HLS的当前性能范围. 根据记录，Mux改变了0美元.04/分钟用于编码完整的编码阶梯和$0.0012/分钟，用于传输流.

让我们开始吧.

开始与LL HLS和Mux视频

在Mux中创建直播流, 发出以下POST请求，该请求可直接从Mux获得文档 (图1). 您可以看到，将减少的延迟标记设置为true，从而启用低延迟HLS.

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

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

图2. 初始化API调用

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

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

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

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

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

图5. 设置编码参数.

然后我开始在OBS中播放音乐会视频，按下流媒体按钮，我就开始运行了(图6). 您可以在图3所示的直播流描述符字段的右侧看到正在播放的视频, 这张照片显然是在直播开始后拍的. 如果您研究图6的右下角，您会注意到CPU利用率为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，因此您可以测试来自多个提供程序的延迟，下面将详细讨论.

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

Second, 该站点测量您提交用于播放的流的延迟，并允许您探索低延迟和流健壮性之间的权衡. 你可以在图8. 视频窗口右侧的当前统计信息显示了延迟和缓冲区大小, 对于大多数服务来说, 包括Mux, 平均在4到8秒之间. 这是默认模式下的延迟.

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

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

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

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

其他LL HLS解决方案

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

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

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

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

另一方面, 没有为LL HLS进行优化的玩家, 像本地HLS播放Chrome扩展, 显示延迟高达26秒, 这证明了LL HLS在非LL HLS玩家上是向后兼容的, 虽然在正常的潜伏期. 在运行iOS 15的iPhone 13 Pro上，由mux制作的流媒体在Safari中播放得非常完美.1.1、延迟仅超过6秒(图11).