关于阿里巴巴:优酷播放体验优化实战三低延时直播

一、前言

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）劣势：海内推广认可度存疑；
新计划的实现不仅解决了现有计划的痛点，在不远的将来还可能孵化出全新的直播业务状态。优酷技术团队会继续在直播技术优化上发力，在晋升优酷视频的播放体验的同时，推动整个行业的技术迭代和倒退。