如何将HLS延时缩短至4秒，HLS+技术详解

在直播应用中，RTMP 和 HLS 是两种较为成熟且广泛应用的流媒体协议，基本上可以覆盖所有客户端。RTMP 是互联网 TCP/IP 五层体系结构中应用层的协议，主要优势就是实时性高，基本可将直播延时控制在3秒以内，因此广泛应用于低延时直播。

HLS是由 Apple 公司实现的基于 HTTP 的流媒体传输协议，拥有性能高、完美支持 iOS等优势。相比于 RTMP 协议，HLS 无需在移动端安装 APP，同时兼容HTML5，因此在移动直播的传播和体验上都拥有巨大的优势。不过HLS 的实时性较差，业界的平均直播延时达在10s ~35s。

在让许多用户最头痛的 HLS 延时问题上，又拍云做了针对性的技术优化，实现了 HLS 的超低延时，将 HLS 延时稳定控制在了 4 秒左右。

HLS 高延时原因分析

HLS 理论上延时=1个切片的时长+ 0-1个td(td是EXT-X-TARGETDURATION，可简单理解为播放器取片的间隔时间) + 0-n个启动切片(苹果官方建议是请求到3个片之后才开始播放) + 播放器最开始请求的片的网络延时（网络连接耗时）。

从延时组成公式可以看出，HLS 的延时主要是以下四部分组成：

服务器端的编码器和流分割器生成 TS 文件的时常，HLS 协议应用于直播视频传输时，是将媒体文件切割成了对应于媒体分段的 TS 文件。
播放器取片的间隔时间，在客户端开始下载之前，必须等待服务器端的编码器和流分割器至少生成一个TS 文件。
客户端下载切片的时间及启动播放所需的切片个数，通常下载完两个媒体文件后才能保证不同分段音视频间的无缝连接。
客户端最开始解码并开始播放的时间。

HLS的延时优化主要是针对前三个部分，第四个部分是取决于用户客户端的性能。

又拍云 4S 延时 HLS+ 技术详解

由于客户端每次请求 TS 或 m3u8 可能都是一个新的连接请求，所以，我们无法有效地标识客户端，一旦出现问题，基本无法有效地定位问题，因此一般服务器都会对传统的 HLS 做一些改进。

又拍云 HLS+ ，又称为流式 HLS 技术，将标准的 HLS 进行流式处理，能大幅度降低标准 HLS 延迟，提高HTML5 端直播兼容性，且具有回源量小、系统简单、排错容易、防盗链、避免 HLS 404 等优势。

又拍云 HLS+ 能够标记每个客户端的 HLS 请求，并为每个 HLS 请求建立起连接，再动态的为每个播放请求生成独立的 M3U8 列表，并动态快速的生成仅针对这个播放请求的小切片文件。

为了解决 HLS 请求不友好的问题，又拍云采用Variant HLS+HTTP 302的方式标识客户端的行为。

1、Variant HLS

首先，下载一条又拍云的 m3u8 文件：

wget http://uplive.bo.upaiyun.com/live/loading.m3u8

然后，打开下载得到的 playlist 文件：

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-ALLOW-CACHE:YES

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-TARGETDURATION:1

#EXTINF:0.998, no desc

http://183.158.35.12:8080/uplive.b0.upaiyun.com/live/loading-0.ts?shp_uuid=e4989f34fcab282e21ef1fd2980284cb&shp_ts=1490172420851&shp_cid=17906&shp_pid=3370578&shp_sip0=127.0.0.1&shp_sip1=183.158.35.12&domain=uplive.b0.upaiyun.com&shp_seqno=0

可以看出又拍云的 HLS+ 支持这种 Variant HLS 方式来标识一条 HLS 连接，同时是使用 UUID 来表示一条 HLS 连接。

2、HTTP 302

首先，以 HTTP 302 方式来请求播放地址。

❯ curl -v http://uplive.b0.upaiyun.com/live/loading.m3u8\?shp_identify\=302 -o playlist

 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                Dload  Upload   Total   Spent    Left  Speed

 0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 183.158.35.59...

* TCP_NODELAY set

* Connected to uplive.b0.upaiyun.com (183.158.35.59) port 80 (#0)

> GET /live/loading.m3u8?shp_identify=302 HTTP/1.1

> Host: uplive.b0.upaiyun.com

> User-Agent: curl/7.51.0

> Accept: */*

>

< HTTP/1.1 302 Found

< Server: marco/0.26

< Date: Wed, 22 Mar 2017 08:54:11 GMT

< Content-Type: text/plain; charset=utf-8

< Content-Length: 259

< Connection: keep-alive

< Access-Control-Allow-Methods: GET

< Access-Control-Allow-Origin: *

< Location: http://183.158.35.19:8080/uplive.b0.upaiyun.com/live/loading.m3u8?shp_uuid=2862b1b817a74cf719b1cd8f554616cd&shp_ts=1490172851450&shp_cid=59553&shp_pid=1730488&shp_sip0=127.0.0.1&shp_sip1=183.158.35.19&domain=uplive.b0.upaiyun.com&shp_identify=302

<

{ [259 bytes data]

* Curl_http_done: called premature == 0

100   259  100   259    0     0   4813      0 --:--:-- --:--:-- --:--:--  4886

* Connection #0 to host uplive.b0.upaiyun.com left intact

打开 playlist 内容：

Redirect to http://183.158.35.19:8080/uplive.b0.upaiyun.com/live/loading.m3u8?shp_uuid=2862b1b817a74cf719b1cd8f554616cd&shp_ts=1490172851450&shp_cid=59553&shp_pid=1730488&shp_sip0=127.0.0.1&shp_sip1=183.158.35.19&domain=uplive.b0.upaiyun.com&shp_identify=302

跳转之后的地址存放真正的 playlist，同时也能够将 UUID 加入到了连接上。

总的来说，不管通过这个方法，最终能通过一个唯一的 ID 来标识一条媒体流，这样在排查问题时就可以根据这个 ID 来定位播放过程中的问题。

又拍云 HLS+延时实测

以下是通过又拍云 HLS+ 直播技术所测试的延迟实例，又拍直播云已可将 HLS 延时控制在4秒左右。