黑色好看版 - 傳送門

正文開始

接下來咱們要來介紹 HLS 協議。

HLS 協議

本篇文章將會分成幾個章節來理解 HLS 協議：

• HLS 協議是要用來完成什麼事情呢 ?
• HLS 協議如何完成它想做的事情呢 ?
• 建立 HLS 的串流傳輸流程。
• HLS 的延遲問題。
• HLS 的特點總結。

HLS 協議是要用來完成什麼事情呢 ?

讓 client 與 server 可以透過 Http 來進行流媒體的傳輸

HLS ( HTTP Live Streaming ) 是由高大尚的蘋果公司所開發，再 HLS 還沒誕生之前，這世界大部份的流媒體傳輸都是被 RTMP 所佔據，最主要的原因在於當時，大部份的電腦都有裝 Flash Player。

而蘋果開發出 HLS 主要有兩個原因：

• 不想被 Flash 綁死，所以它大部份的設備都慢慢的把 Flash 拔掉(當時)。
• RTMP 有個問題就是，它不是透過 HTTP 來進行傳輸，所以它很有可能會被一些防火墻防掉。

HLS 協議如何完成它想做的事情呢 ?

它將聲音切成一小個一小個檔案，然後 client 就一個一個發 http 去下載。

基本上 http 本身不能說它有支援傳輸串流媒體機制，但它的確有提供一個叫做http chunk的東西，可以將要傳輸的數據分成多個來傳輸。但是如果要用這個方法來傳輸串流媒體，它的確可以傳輸流容器過去，但是問題要如何進行解析，那又需要在自幹一些標準，不然接受端如何知道要播放，這也是為啥說純 http 本身不提供串流媒體的功能。

因此蘋果就基於 HTTP 協議來開發出另一個應用層的協議 HLS，為了可以使用 HTTP 來進行串流媒體傳輸。

建立 HLS 的串流傳輸流程。

它的基本概念如下圖，首先它會將一段聲音或影像編碼，轉換成兩種檔案。

• .m3u8 : 它是個索引檔，裡面記錄了這一段聲音，被分割成那些檔案存放。
• .ts : 它是實際上的影音檔，然後別忘了 .ts 為流容器，這也代表他可以一邊下載一邊聽。

然後這個為實際上 .m3u8 檔案內所放的東西，其中比較重要的 EXTINF 代表這個 .ts 共有 4 秒長度，這也代表這一段聲音總共有 4 x 6 = 24 秒的長度。

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:5
#ID3-EQUIV-TDTG:2016-11-26T02:40:23
#EXT-X-MEDIA-SEQUENCE:376
#EXT-X-TWITCH-ELAPSED-SYSTEM-SECS:1511.137
#EXT-X-TWITCH-ELAPSED-SECS:1508.980
#EXT-X-TWITCH-TOTAL-SECS:1535.137
#EXTINF:4.000,
index-0000000377-6zCW.ts
#EXTINF:4.000,
index-0000000378-vHZS.ts
#EXTINF:4.000,
index-0000000379-Gkgv.ts
#EXTINF:4.000,
index-0000000380-PNoG.ts
#EXTINF:4.000,
index-0000000381-h58g.ts
#EXTINF:4.000,
index-0000000382-W88t.ts

接下來 client 如果要聽這一段聲音時，它會先用 http 發送一段請求，就如同下面的範例。

https://127.0.0.1/test.m3u8

然後它的過程如下，Server 會回傳個 .m3u8 檔案回來，然後它的內容就是說明這聲音檔被分割成那些 .ts 檔案，然後因為 Client 是遵循 HLS 協議，因此會在去取得這些 .ts 檔案來播放。

HLS 的延遲問題

HLS 如果是要用在那種點播 (就是線上點選看影片那樣) 類型的應用，那是沒有什麼太大的問題，但是如果是在互動直動這種應用，那它就有很大的問題。

因為基本它 HLS 延遲大約 10 秒左右。

也就是說直播主話說以後，要大約 10 秒後才會到聽眾端。

那為什麼延遲會如此的長呢 ?

咱們以下面的 .m3u8 為說明，下面的每一個 .ts 檔都為 4 秒，這也代表這一段聲音總共為 4 x 6 = 24 秒的長度，如果這是在直播的情況下，那不就代表這個直播主事實上已經說完了 24 秒的話了，對吧 ?

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:5
#ID3-EQUIV-TDTG:2016-11-26T02:40:23
#EXT-X-MEDIA-SEQUENCE:376
#EXT-X-TWITCH-ELAPSED-SYSTEM-SECS:1511.137
#EXT-X-TWITCH-ELAPSED-SECS:1508.980
#EXT-X-TWITCH-TOTAL-SECS:1535.137
#EXTINF:4.000,
index-0000000377-6zCW.ts
#EXTINF:4.000,
index-0000000378-vHZS.ts
#EXTINF:4.000,
index-0000000379-Gkgv.ts
#EXTINF:4.000,
index-0000000380-PNoG.ts
#EXTINF:4.000,
index-0000000381-h58g.ts
#EXTINF:4.000,
index-0000000382-W88t.ts

以上面的例子，我們可以稱這一段聲音有 5 個片段，然後每個片段為 4 秒鐘，那我想問個問題。

片段的數量與長度可以調整嗎 ?

當然可以 !

但是問題就在於要調整的如何 ?

首先來看看官網推薦：

官網建議 3 個片段，每個片段為 10 秒

但是如果使用這種建議，那就代表至少會延遲 30 秒，不過相對的看影片時就不會卡頓。

那如果縮小呢 ? 例如每個片段為 1 秒呢 ? 這樣的確可以降低延遲，但是相對的 Server 負擔會非常的龐大，非常的不建議這樣做。基本上如果真的要做那種很在意延遲性的應用，例如直播互動，請直接放棄掉 HLS。

HLS 的特點總結

• HLS 的延遲性高，如果是要做互動直播這種類型的應用，請放棄他。
• HLS 支援影像編碼為 H.264。
• HLS 支援聲音編碼為 AAC、MP3。
• HLS 使用 .ts 流容器。
• HLS 支援可以根據網路狀態，動態的調整碼率，比較白話文點就是你網路不好，他會自動讓你的畫質變差點兒，而不會讓你卡頓。
• HLS 以 HTTP 為基礎，所以看影片暢通無比，這裡是指如果你要連到某個 HLS Server 看迷片，比較不會因為一些防火墻或啥的問題，而不能看。
• 它有個大靠山，大蘋果 !

參考資料

• 直播-拉流和推流概述
• HLS协议深入分析——时间线介绍（一）
• 让Chrome看不了WWDC直播的HLS技术详解
• 在线视频之HLS协议—学习笔记：M3U8格式讲解及实际应用分析
• 官網：