如何将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 的延时主要是以下四部分组成:

  1. 服务器端的编码器和流分割器生成 TS 文件的时常,HLS 协议应用于直播视频传输时,是将媒体文件切割成了对应于媒体分段的 TS 文件。

  2. 播放器取片的间隔时间,在客户端开始下载之前,必须等待服务器端的编码器和流分割器至少生成一个TS 文件。

  3. 客户端下载切片的时间及启动播放所需的切片个数,通常下载完两个媒体文件后才能保证不同分段音视频间的无缝连接。

  4. 客户端最开始解码并开始播放的时间。

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

可以看出又拍云的 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 

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

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

又拍云 HLS+延时实测

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

推荐阅读:

让Chrome看不了WWDC直播的HLS技术详解
技术干货|直播转码系统架构与实践
无连麦,不直播,都在说的直播利器连麦互动到底是啥?

posted @ 2017-06-20 10:44  又拍云  阅读(15078)  评论(2编辑  收藏  举报