实时低延迟流媒体 第三部分：HLS

本文来自BITMOVIN，由Jameson Steiner编辑，是实时低延迟流媒体系列的最后一部分。

前两篇文章介绍了OTT和LL-DASH中低延迟流媒体的基本原理。 本文将重点介绍使用苹果的HTTP Live Streams（HLS）协议时的延迟以及如何减少延迟时间。

以下是前两篇文章对应的帖子链接：

实时低延迟流式传输

为什么HLS的延迟较高

当前规范中的HLS优先考虑流可靠性而不是延迟。可以接受更高的延迟来换取稳定的播放而不会被打断。在6.3.3节中。播放媒体播放列表文件时，HLS规范指出播放客户端不应选择从播放列表文件末尾开始少于三个目标时长的片段。

满足此要求将导致至少3个目标持续时间的延迟。假设当前HLS部署的典型目标持续时间为10或6秒，那么最终将获得至少30或18秒的等待时间，这远不算低延迟。即使选择忽略上述要求，片段的产生，传输和使用的全过程通常也会造成缓冲区欠载和播放中断的高风险。

上面描述的此直播流的HLS媒体播放列表如下所示：

低延迟HLS之路

2017年，Periscope——当时最受欢迎的用于用户生产内容的实时流传输的平台——研究了流传输解决方案，以一种更具可扩展性的方式替代其基于RTMP和HLS的混合方法。要求提供与RTMP类似的端到端延迟，但以更具成本效益的方式进行，因为他们的应用场景是流向大量受众。Periscope展示了他们针对高延迟问题的解决方案：采用了苹果公司的HLS协议，进行了两项基本更改，并将其称为低延迟HLS（LHLS）：

1. 使用HTTP/1.1块传输编码来传输片段
2. 片段在可用之前在HLS播放列表中被通知

实际上这些简单的概念是当今基于OTT的低延迟流方法（例如LL-DASH）的关键要素。Periscope的工作很可能引发并影响了围绕低延迟流传输的发展，例如LL-DASH，以及社区驱动的旨在修改HLS以减少流传输延迟的计划，该计划始于2018年底。

LHLS社区提案的核心与上述概念相同。应使用HTTP CTE将片段分段加载，并应使用播放列表中的新＃EXT-X-PREFETCH标记来指示不完整片段的较早可用性。在下面的示例中，客户端可以加载并使用6.ts的当前可用数据，并当其随着时间的推移变得可用时，继续这样做。此外，即使7.ts片段尚未开始产生，也可以提早请求它以节省网络往返时间。还值得一提的是，LHLS提案保留了完全的向后兼容性，允许标准HLS客户使用此类流。这是提议实施的要点。

完整的提案可以在这个链接中阅读：

https://github.com/video-dev/hlsjs-rfcs/blob/a6e7cc44294b83a7dba8c4f45df6d80c4bd13955/proposals/0001-lhls.md。

媒体行业中多家公司的人们共同为该提案出了力，并希望HLS背后的推动者苹果公司也可以加入该提案并将其纳入正式的HLS规范中。但是，结果与预期的大不相同，因为苹果推出了自己的解决方案，也就是他们在2019年的全球开发者大会上展示的一种截然不同的方法。

尽管这种方法是（并保持）专有方法，但某些公司（例如Twitch）已在其生产系统中成功使用了它。

苹果的低延迟HLS流

在本节中，我们将介绍苹果的低延迟HLS的规范中的一些要求。

01

部分媒体片段的生成

虽然HLS内容分为多个单独的片段，但在低延迟HLS中，每个段还包含可由客户端独立寻址的部分。例如，一个6s的时间段可以由30个持续时间为200ms的部分组成。根据容器格式，这些部分可以表示一系列CMAF块或TS数据包。片段的这种划分使端到端延迟与较长的片段持续时间解耦，并允许客户端在可用时尽快加载段的一部分。与LL-DASH相比，这是通过使用HTTP CTE来实现的，但是，MPD文件不会通告片段的单个部分/块。

使用新的EXT-X-PART标签记录部分片段。请注意，部分片段仅针对播放列表中的最新片段进行记录。此外，还提供了部分段（filePart272.x.mp4）和相应的完整段（fileSequence272.mp4）。

部分片段也可以引用同一文件，但引用的字节范围不同。因此，与对每个部分分别发出请求相比，客户可以通过单个请求加载多个部分分段，并节省往返行程（如下所示）。

02

预加载提示和媒体下载的阻止

即将可用的部分片段在播放列表中的实际可用性之前通过新的EXT-X-PRELOAD-HINT标签进行记录。这使客户端可以及早打开请求，并且一旦数据可用，服务器就会响应。这样，客户端可以节省请求的往返时间。

03

播放列表增量更新

对于低延迟HLS，客户端必须更频繁地更新HLS播放列表。播放列表增量更新可用于减少每个播放列表请求传输的数据量。新的EXT-X-SKIP标签将客户端已经收到的播放列表的内容替换为先前的请求。

04

播放列表重载的阻止

发现新片段可用于HLS实时流的方法通常是由客户端以固定间隔重新加载播放列表文件并检查是否添加了新片段来应用的。在低延迟流传输的情况下，期望避免在（部分）片段在播放列表中变得可用与客户端发现其可用性之间的任何延迟。使用播放列表重新加载方法，在最坏的情况下，这种发现延迟可能与重新加载时间间隔一样高。

利用阻止播放列表重新加载的新功能，客户端可以指定他们正在等待的未来片段的可用性，服务器将必须保留该播放列表请求，直到该特定片段在播放列表中可用为止。使用播放列表请求上的查询参数指定要等待的片段。

05

渲染报告

当以低延迟播放时，快速的比特率自适应对于避免由于缓冲区不足导致播放中断至关重要。要在播放列表切换期间保存往返行程，播放列表必须通过新的EXT-X-RENDITION-REPORT标记来指示渲染报告，该标记表示有关最新片段和部分的渲染情况。

结论

有关苹果低延迟HLS的更多详细信息，请查看规范文件和最新的IEFT草案，其中包含针对HLS的低延迟扩展。链接地址如下

https://developer.apple.com/documentation/http_live_streaming/enabling_low-latency_hls

https://datatracker.ietf.org/doc/draft-pantos-hls-rfc8216bis/

可以得出结论，与标准HLS相比，低延迟HLS显著增加了复杂性。服务器的职责将从简单的服务网段扩展到支持客户端用于节省网络往返并加速网段交付的几种其他机制，从而最终实现更低的端到端延迟。考虑到该规范仍会更改，并且尚未定稿，流媒体供应商可能会花一段时间才能采用它，而我们最终会在市面上看到低延迟的HLS。简而言之，可以使用HLS进行实时的低延迟流传输，但是要付出较大的服务器复杂性代价。目前正在研发各种措施来降低复杂性和服务器负载，但是要实现这一点，主流流提供者将需要更广泛的采用低延迟HLS。