1 概述
HTTP Live Streaming（HLS）是一個由蘋果公司提出的基於 HTTP 的流媒體網絡傳輸協議。是蘋果公司 QuickTime X 和 iPhone 軟件系統的一部分。它的基本原理是在服務端把文件或媒體流分成許多小塊的基於 HTTP 的文件或媒體流，客戶端在播放碼流時，可以根據自身的帶寬及性能限制，在同一視頻內容的不同碼率的備用源中，選擇合適碼率的碼流進行下載播放。在傳輸會話開始時，客戶端首先需要下載描述不同碼流元數據的 M3U8 索引文件，用於尋找可用的媒體流。
與基於 UDP 的 實時傳輸協議（RTP）協議不同，HLS 只請求基本的 HTTP 報文，因此可以穿過任何允許 HTTP 數據通過的防火牆或代理服務器。這也便於使用傳統的 HTTP 服務器作爲源，並廣泛使用基於 HTTP 的內容分發網絡來傳輸媒體流。
2 HLS 協議簡介
HLS 協議格式可簡單歸納如下：
網絡協議： HTTP
封裝格式： TS
編碼格式： 視頻編碼格式 -> H.264 音頻編碼格式 -> MP3、AAC、AC-3
索引文件： M3U8
需要說明的是，目前已有廠家實現了 H.265 的 HLS 編碼。在封裝層面，除了 MPEG-2 TS 封裝外，在 WWDC2016 上，蘋果宣佈了HLS對分段 MP4（fMP4）文件字節尋址的支持，爲 HLS 向 MPEG-DASH 的兼容提供了可能。
根據媒體流的生成及流向，HLS 的結構可劃分爲如下幾個部分：
- Audio/Video inputs 源可以是任意格式，可以是離線文件或實時碼流。
- Server 接收到視頻源後，Media encoder 將源視頻轉碼成 HLS 支持的編碼格式和封裝格式，根據需求可輸出多個碼率分別送至 Stream segmenter。
- 在 segmenter 中被切分成指定大小或時間長度的 TS 切片，並生成索引文件 M3U8。
- Distribution 是一個 HTTP 文件服務器，負責將流媒體文件推送出去或響應客戶端的請求。
- 客戶端只要訪問一級 M3U8 文件路徑就能自動播放 HLS 視頻流了。
那麼，M3U8 到底是個什麼文件呢？
M3U8 文件其實就是以 UTF-8 編碼的 M3U 文件，該文件本身不能播放，只是用於存放待播放視頻流的基本信息。下圖表示了 M3U8 文件的結構。
HLS 有兩級索引，第一級索引存放的是不同碼率的 HLS 源的 M3U8 地址，也就是二級索引文件的地址；第二級索引則記錄了同一碼率下 TS 切片序列的下載地址。客戶端獲取一級 M3U8 文件後，根據自己的帶寬，去下載相應碼率的二級索引文件，然後再按二級索引文件的切片順序下載並播放 TS 文件序列。
一個典型的一級索引文件如下：
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000, RESOLUTION=720x480
mid_video_index.M3U8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=800000, RESOLUTION=1280x720
wifi_video_index.M3U8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=3000000, CODECS="avc1.4d001e,mp4a.40.5", RESOLUTION=1920x1080
h264main_heaac_index.M3U8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=64000, CODECS="mp4a.40.5"
aacaudio_index.M3U8
其中，
#EXTM3U
格式標籤，標明該文件是一個 Extended M3U 播放列表文件
#EXT-X-STREAM-INF
特定流標籤，指示了該流的格式信息：PROGRAM-ID 節目 ID，一般不用考慮；BANDWIDTH：指定流的帶寬；RESOLUTION：視頻分辨率；如果存在音頻分級，則需指定音頻的編碼格式 CODECS，如上例中的最後兩項。
#EXT-X-STREAM-INF下面緊接的一行，如mid_video_index.m3u8則是對應流的二級索引文件地址，通過下載該二級索引文件，便可得到媒體切片的信息。
客戶端可以自己判斷自己的現行網絡帶寬，來決定播放哪一個視頻流。也可以在網絡帶寬變化的時候平滑切換到和帶寬匹配的視頻流。
二級索引文件格式按照播放模式分類如下：
（1） VOD 模式
點播 VOD 的特點就是當前時間點可以獲取到所有 ts 文件，二級索引文件中記錄了所有 ts 文件的地址。這種模式允許客戶端訪問全部內容。
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:3
#EXTINF:9.009,
http://media.example.com/first.ts
#EXTINF:9.009,
http://media.example.com/second.ts
#EXTINF:3.003,
http://media.example.com/third.ts
#EXT-X-ENDLIST
仍然是以#EXTM3U開頭
#EXT-X-TARGETDURATION： 表示切片的最大時長，單位是秒。#EXT-X-TARGETDURATION:10 表示列表中表示的每個切片時長不超過 10 秒。
#EXT-X-VERSION：表示協議兼容性版本。
#EXTINF：切片的實際時長，若要求取整，則其數值不能大於 EXT-X-TARGETDURATION 的值。
http://media.example.com/first.ts：對應的切片文件（路徑），可以是絕對路徑，也可以是相對路徑。
#EXT-X-ENDLIST：表示整個碼流的結束，不再向後附加新的切片列表。
（2） Live 模式
Live 模式就是實時生成 M3U8 和 ts 文件。它的索引文件一直處於動態變化的，播放的時候需要不斷下載二級索引文件，以獲得最新生成的 ts 文件播放視頻。如果一個二級索引文件的末尾沒有 #EXT-X-ENDLIST 標誌，說明它是一個 Live 視頻流。
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:2680
#EXTINF:7.975,
https://priv.example.com/fileSequence2680.ts
#EXTINF:7.941,
https://priv.example.com/fileSequence2681.ts
#EXTINF:7.975,
https://priv.example.com/fileSequence2682.ts
#EXT-X-MEDIA-SEQUENCE：媒體序列號，表示出現在當前 M3U8 文件中的第一個 Segment 的序列號。
Live 模式的 M3U8 一般用於直播，列表中的文件數有限制，推薦配置中是 3 個，服務端會實時更新該列表，刪除最開始的 Segment，並向後面添加新生成的 Segment。因此，這種模式下，當網絡帶寬不足時，客戶端來不及下載新的 M3U8 和對應的切片文件，會導致切片丟失，播放卡頓。
2.1. HLS 優勢
- HLS 協議本身實現了碼率自適應，不同帶寬的設備可以自動切換到最適合自己碼率的視頻播放。
- 解決 RTMP 協議存在的一些問題。比如 RTMP 協議不使用標準的 HTTP 接口傳輸數據，所以在一些特殊的網絡環境下可能被防火牆屏蔽掉。但是 HLS 由於使用的 HTTP 協議傳輸數據，不會遇到被防火牆屏蔽的情況。
- RTMP 是一種有狀態協議，很難對視頻服務器進行平滑擴展，因爲需要爲每一個播放視頻流的客戶端維護狀態。而 HLS 基於無狀態協議（HTTP），客戶端只是按照順序使用下載存儲在服務器的普通 TS 文件，做負責均衡如同普通的 HTTP 文件服務器的負載均衡一樣簡單。
2.2. HLS 劣勢
HLS 存在延遲過大的劣勢。採用 HLS 直播的視頻流延時一般在 10 秒以上，使用推薦配置時延遲大概在 30s，而 RTMP 直播的延遲最低可達到 3、4 秒，因此，在對實時性要求較高的場合，如互動直播，就要慎用 HLS 了。