共计 4764 个字符，预计需要花费 12 分钟才能阅读完成。
一、前言
5G 到来后用户的网络速度逐步进步，同时用户对直播提早等播放体验的要求也越来越高，在此背景下，优酷技术团队联合业内支流的直播技术架构提出了两种基于 HLS（HTTP Live Streaming）的低提早直播计划（Low Latency HLS），并且正式利用到了优酷直播业务。
业内以后支流直播低延时计划优缺点比照如下：
1、RTMP（Real-Time Messaging Protocol）
长处：
1）专门为流媒体开发的协定，对 FLASH 的反对较好；
2）提早较低，个别在 1 - 3 秒；
毛病：
1）基于 TCP（Transmission Control Protocol）传输，应用非公共端口（1935），可能会被防火墙拦挡；
2）RTMP 是 Adobe 的公有协定，有些设施无奈间接播放，可能须要借助于第三方模块；
2、HTTP-FLV（Hypertext Transfer Protocol- Flash Video）
长处：
1）基于 80 端口，能够比拟好的穿透防火墙；
2）可通过 302 跳转灵便调度和负载平衡；
3）反对 HTTPS（HyperText Transfer Protocol Secure）加密传输，并可兼容多端；
毛病：
1）因为它的传输个性，会让流媒体资源缓存在本地客户端，在保密性方面不够好；
2）切换清晰度须要切换播放器实例，所以无奈实现平滑切换，切换的过程中可能呈现画面断层（画面停在某一帧、黑屏加载等），在网络抖动显著的状况下体验会更差；
3、HLS（HTTP Live Streaming）
长处：
1）支流平台对 HLS 的反对水平比拟高，利用范畴较广；
2）基于 80 端口，可防止防火墙拦挡；
3）反对平滑切换清晰度；
4）CDN 对协定的反对比拟好；
毛病：
1）提早较高，个别在 10 秒以上；
2）间接通过减小 GOP（Group of pictures）的形式升高延时时容易减少码率；
4、RTP（Real-time Transport Protocol）
长处：
1）实时性较好，个别提早在 1 秒以内；
2）基于 UDP（User Datagram Protocol），传输效率较高；
毛病：
1）罕用于视频会议等，拓展性个别。PGC（Professionally-generated Content）、OGC（Occupationally-generated Content）直播利用较少；
2）对高码率的反对较差，个别为了流畅性会就义码率；
通过比拟上述直播计划的优缺点，能够看出 HLS 协定最适宜直播场景。海内厂商对 HLS 的认可度也很高，苹果也始终在大力推广基于传统 HLS 的低提早直播计划，因而，优酷技术团队抉择了 LHLS 计划。
二、为什么会有提早
想搞清提早的前因后果，须要剖析 HLS 的文件构造：
简略来说，HLS 蕴含两局部，m3u8 文件（playlist）和承载具体媒体内容
的文件（ts、cmaf、fmp4 等），客户端依据 m3u8 的批示下载媒体内容并定时刷新 m3u8 文件取得最新内容列表。
以下是一个蕴含多种码率的 master playlist（如果没有多个码率，这个 m3u8 playlist 能够没有）：
以下是其中一个 playlist 的 m3u8 内容（如果只有一个码率，能够只提供这个 m3u8）：
以上呈现的 tag 形容如下，还有很多 tag，具体能够参考 RFC：
1. playlist 刷新、播放机制
EXT-X-TARGETDURATION 通常就是 GOP（Group Of Picture）的大小，如果 EXT-X-TARGETDURATION 是 4 秒，那么须要 4 秒编码实现一个片段并更新 playlist，客户端采纳轮询计划来获取下一版 playlist，轮询的机会在 (4,8) 秒区间内，都将取得仅蕴含第一份片段的 playlist，并且 playlist 的申请和响应自身须要一个 RTT（round-trip time）来回传，在挪动网络上可能减少数百毫秒的提早，之后才开始下载文件片段。领有足够多数据当前，播放器能力开始播放（有的播放器要缓存 2 - 3 个片段才开始播放，提早可能超过 12 秒）。
2. CDN 缓存机制
如下图所示，源站曾经后退到第四个片段，然而 CDN 边缘节点还缓存着上一个版本（只蕴含 3 个片段）的 playlist，必须等文件的 TTL 过期边缘节点才会去获取最新版本的列表，最差状况下又要多期待一个 TTL。而这个缓存 TTL 也不能取消，如果每个端上的申请达到 CDN 边缘节点时都去找源站要最新版本，源站就可能会被流量冲垮。
3、网络因素
网络因素也是造成提早的其中一个次要因素，对提早的影响大小与网络情况无关，具体从几百毫秒到几秒不等。
三、基于 Apple 标准的规范计划——从协定自身进行优化
为了将 10-30 的提早升高到 2 秒以下，LHLS 在 Apple 标准的根底上提出了 6 点改良：
（1）缩小片段公布提早
（2）优化片段发现机制
（3）打消片段申请工夫
（4）m3u8 采纳增量降级机制
（5）减速不同码率直播流切换速度
（6）基于网络打分的动静起播策略模型
上面具体介绍每个优化点：
（1）缩小片段公布提早
为了缩小公布提早，引入了 EXT-X-PART 和 EXT-X-PART-INF tag，示例 m3u8 如下所示，也就是原来须要生产实现整个 ts 才公布进去，当初通过 part 的模式分小段公布进去。
（2）优化片段发现机制
采纳阻塞式 m3u8 加载（EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES）客户端能够依据收到的片段数和 EXT-X-MEDIA-SEQUENCE 基数，计算出下一个片段的序号，而后间接找服务器申请对应的 m3u8，
GET https://example.com/live.m3u8…（该申请示意，当值班流中呈现 1803 的 ts 的时候，进行阻塞，返回 m3u8 内容）, 联合 1，容许服务端下发 part 的话，则发送申请 GET https://example.com/live.m3u8…
（该申请示意，当直播流中呈现 1803 的第一局部_HLS_part= 0 的时候就进行阻塞，返回 m3u8）, 具体过程是这样：
m3u8 外面蕴含 EXT-X-MEDIA-SEQUENCE，客户端能够依据收到的片段数和 EXT-X-MEDIA-SEQUENCE 基数，计算出下一个片段的序列号，而后间接找服务端申请对应的 m3u8：
GET https://example.com/live.m3u8…
上述申请示意当直播流中呈现 1803 的 ts 的时候，进行阻塞，返回 m3u8 内容。
联合 1 的内容，容许服务端下发片段 part 的话，则申请如下：
GET https://example.com/live.m3u8…
上述申请示意当直播流中呈现 1803 的第一局部 (_HLS_part=0) 的时候就进行阻塞，返回 m3u8 内容。
（3）打消片段申请工夫
上述申请的最初一部分——_HLS_push 比拟奥妙，也是这次 HLS 协定降级的一个很大的扭转，要求服务器反对 HTTP/2，次要应用多路复用和 server push 等能力，申请 playlist 的时候就间接将片段 /part 的内容追随 push 下来，缩小一个 RTT 提早。
通过上述三点改良后，能够看到相比之前的旧版 HLS 计划，当初能够在很低的提早下就取得首帧数据开始解码播放，图上示例的 part 时长是 0.5 秒，网络传输 0.5 秒的话，实践上客户端察看到的提早能够低到 1 秒左右，part 长度能够进一步放大，比方 0.2 秒，以取得更低的提早。
（4）m3u8 采纳增量降级机制
因为 m3u8 的申请可能高达每秒钟 3 - 4 次，为了进一步缩小网络传输数据大小，引入了增量更新机制，
其中 EXT-X-SERVER-CONTROL: CAN-SKIP-UNTIL=36.0 通知客户端，比以后直播前沿数据早 36 秒以上的数据会被疏忽。这个数值要求是 EXT-X-TARGETDURATION 的 6 倍以上。客户端就能够通过申请的参数_HLS_skip=YES 通知服务端下发增量更新内容。
这个性能在一些场合比拟有用，有些直播流容许用户往前回看一段时间，所以它们的 m3u8 文件会很大，上百 K 都有可能。应用增量更新机制能极大减小传输量。
（5）减速不同码率直播流切换速度
实现计划是在 m3u8 的最初带上 EXT-X-RENDITION-REPORT（如：GET https://example.com/1M/live.m…），通知客户端其它码率直播流的以后停顿 (片段序号和 part 序号) 和加载地址，当客户端决定要切换到另一个直播流上的时候，它不必发动一个新的申请，只有间接在原来的连贯上申请即可（不过在苹果的参考实现上并没有实现这部分内容）。
（6）基于网络打分的动静起播策略模型
依据用户的信号强度、进口带宽、丢包率等参数确定一个网络打分模型并基于该打分模型对用户的网络进行量化（如：网络较好：3 分、网络个别：2 分、网络较差：1 分、无网络：0 分等），依据网络的量化后果确定起播地位，如：3 分（网络较好）时从倒数第 3 个 part 起播，2 分时从倒数第 5 个 part 起播等，该动静策略模型失效后可很好的均衡提早与卡顿的体验，教训证相较于 HLS 直播，LHLS 在卡顿率无明显增加的状况下，提早可升高 50%-80%。
四、社区 LHLS 计划——联合 http chunked 进行优化
在苹果推出基于 HLS 的 LHLS 低提早草案之前，各次要技术社区就曾经有过相似摸索，它的计划的次要技术点是基于 HTTP/1.1 的分块传输编码 Chunked Transfer Coding 机制（RFC 2616），分块传输编码次要用于发送未知长度、客户端申请时还未齐全筹备好的数据，用一个 HTTP 响应数据简略阐明如下：
下面这个过程能够看出，分块传输编码天生适宜用于传输“还未到来的”HLS 片段数据。社区 LHLS 计划对规范 HLS 做的外围变动是提前几个片段时长就将片段网址增加到播放列表中。举例来说，当直播流正在启动并且流的第一帧从推流端达到服务器时，服务器将立刻公布蕴含三个 (数量可配置) 片段的 HLS 媒体播放列表。当客户端收到播放列表时，它们会申请第一个 ts 分片（有的是间接申请全副三个分片，教训证该形式可能会造成带宽竞争，故对此作了深度革新）。服务器应用分块传输编码来响应每个申请。对于第一段的申请将首先取得在申请达到时在该段中累积的数据，然而之后的数据（在该段的残余持续时间内）将在真正达到时候才传输给客户端。当接管完第一片 ts 数据后间接发送第二片的申请，以此类推。
在播放列表可用之前就播送片段的益处是它打消了因为客户端播放列表轮询频率和 CDN 高速缓存中的播放列表 TTL 而导致的播放列表提早问题。因为片段在它们理论蕴含媒体之前几秒钟被播送，如果播放列表能够被 CDN 聚合申请，就不会影响提早。客户端会提前几秒钟获知行将到来的片段并申请它们，这样就能够在服务器取得数据后立刻接收数据。
五、LHLS 技术计划比照
1、规范 LHLS 计划：
（1）劣势：基于 Apple 标准设计的 LHLS 低延时计划既反对 Apple 标准规范，又反对灵便扩大，便于用户播放体验的优化（尤其是卡顿与提早的优化），同时反对海内推广（目前海内次要认可该种形式）；
（2）劣势：要用到 HTTP/ 2 的一些新个性（如：多路复用和 server push 等），因而须要 CDN 端反对 HTTP/2。只反对 HTTP/1.1 的厂商就受到了限度，不能施展全面的劣势；
2、社区 LHLS 计划：
（1）劣势：基于 http chunked 分块传输编码机制，原生反对事后未知 filesize 的流传输，实现起来较不便；
（2）劣势：海内推广认可度存疑；
新计划的实现不仅解决了现有计划的痛点，在不远的将来还可能孵化出全新的直播业务状态。优酷技术团队会继续在直播技术优化上发力，在晋升优酷视频的播放体验的同时，推动整个行业的技术迭代和倒退。
