如何将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      

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秒左右。

推薦閱讀：

讓Chrome看不了WWDC直播的HLS技術詳解

技術幹貨|直播轉碼系統架構與實踐

無連麥，不直播，都在說的直播利器連麥互動到底是啥？