优酷播放体验优化实战（三）--低延时直播

一、前言

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