低延迟HLS规范即将定稿

对基于http的段或块“流”交付的一致的低延迟方法的需求已经讨论了十多年. 早在2011年, 随着动态自适应流媒体通过HTTP(简称DASH)由电影专家组批准, 由于基于http的交付会导致6到30秒的延迟，因此出现了一些危险信号，警告说可能会“把我们拖入延迟交付的困境”. 这些警告是在 流媒体 杂志、在线论坛、流媒体展和其他行业活动.

十年过去了，人们似乎听到了这些担忧. 从2019年开始, 苹果公司是MPEG DASH批准的一部分，但没有实施国际标准的任何部分, 在转向分段MP4 (fMP4)文件的字节范围寻址之前，他们转而依靠MPEG-2传输流(m2ts)方法，开始讨论其HTTP 在线直播 (HLS)交付规范的低延迟版本的可能性.

苹果并不是第一个讨论HTTP传输低延迟方法的公司, 并多次尝试使用DASH和通用媒体格式(CMAF)。. 但既然是苹果, 谁主导了基于http的HLS交付, 许多业内人士都在等着听苹果公司的罗杰·潘托斯对这个话题的看法.

Pantos有一个互联网工程任务组(IETF) 规范关于HLS的草案已经有十多年了. 第一个HLS规范, 5月1日, 2009, 是由Pantos撰写的，从那以后被亲切地称为“Pantos规范”，作为HLS建议和如何向苹果提供HLS流的最佳实践的简称, 安卓, 以及其他机顶盒设备.

In 2017, 在23个不同版本之后, 每次持续约5个月, 信息规范进入下一步，成为RFC 8216. 向RFC的转变意味着对评论的请求是将规范最终确定为更正式的IETF标准的最后一步. 除了Pantos之外，MLB Advanced Media group也是唯一一个非苹果公司的 RFC 8216.

In 2019, 虽然, Pantos已经看到了其他基于段的HTTP交付方法如何开始解决低延迟问题, 并着手以低延迟版本重新定义HLS. 他是在苹果全球开发者大会(WWDC 2019)的一次演讲中这样做的，他介绍了低延迟HLS的概念，并提出了始终以HLS所知的近三分之一的典型延迟交付的要求. 这些建议在苹果开发者网站低延迟HLS (LL-HLS)的初始版本和现在“几乎最终”版本.

业界迅速给出了反馈——既有正面的，也有负面的, 在很大程度上, 对最初的Pantos LL-HLS规范持否定态度. 像这样, 最新版本的Pantos规范, 2020年4月起, 与Pantos之前在WWDC和我们自己的流媒体西部2019年的演讲相比，这是一个很大的转变.

一个很大的变化是，新规范打算完全取代所有非低延迟HLS规范. 事实上，潘托斯在 2020年4月版该文档已废弃RFC 8216."

另一个重大变化是最新的Pantos规范取消了所有用于交付LL-HLS的HTTP服务器使用HTTP/2 PUSH的要求.

在2019年的流媒体西部, Pantos对HTTP/2赞不绝口，认为它是一种通过单个HTTP连接发送和接收多个请求的方式, 它有可能减少臭名昭著的喋喋不休的HTTP / TCP，从而减少开销和请求流水线.

然而，业界的反馈是，许多HLS交付商店的现有基础设施都是基于原始的HTTP服务器版本, 而且苹果方面对过渡到HTTP/2的容易程度有不切实际的假设.

这将我们带到2020年9月的当前状态. 而2020年4月版本的Pantos规范仍然推荐HTTP/2 PUSH, 建议被移到了附录B. 在它的位置, 这是显性的, 所需的“提示”扩展, 适当地称为EXT-X-PRELOAD-HINT.

THEOplayer的Pieter-Jan Speelmans解释了这种转变, 以及它在消除服务器和最终用户玩家之间的额外往返方面的实际好处, 但他也指出，苹果的规格总是会发生变化.

而不是使用HTTP/2推送, 而苹果则添加了一个名为#EXT-X-PRELOAD-HINT的新标签,斯佩尔曼斯写道. 用这个标签, 发布低延迟HLS流的服务器需要宣布下一个可用媒体数据最有可能的位置. 这允许播放器客户端执行请求, 允许数据在段的下一部分可用时立即流入. 然后可以重复这个过程, 允许在加载新媒体数据时删除额外的往返时间(这是使用HTTP/2推送的主要原因)."

作为正在进行的关于LL-HLS的讨论的一部分，以及它如何与DASH已经完成的其他工作以及业界对通用媒体格式(CMAF)的尝试相结合。, 斯佩尔曼斯将成为圆桌会议讨论 9月23日. 还有Wowza和Fastly的代表, Speelmans将进一步解释苹果从HTTP/2的转变，以及这对采用整个LL-HLS生态系统意味着什么.

[罗杰·潘托斯在2019年流媒体西部演讲的照片，由埃里克·舒马赫-拉斯穆森拍摄。.]