HLS 協定

HLS

HLS, HLS 是一基於 HTTP(S) 的 串流媒體協議，為 Apple 所開發，是目前最受歡迎的技術, 他分為兩種 session：隨選視訊、直播（這邊主要談的是隨選視訊的部分），共有以下幾種特點：

• 支援影像編碼為 H.264，支援的聲音編碼為 AAC、MP3，並且使用 .ts 為容器

• 接收方可以根據網路狀況自動調整不同解析度

• 支援加密

• 同支影音內容可以有不同的播放條件, eg: 切換字幕、切換解析度(依流量)

PS: 常被問到串流影片佔用的硬碟空間: 以 HD(1280x720/30fps)規格的40小時長度的影片為例，約佔 32GB(此數據僅供參考，實際編碼及內容會不同)。

HLS(HTTP Live Streaming)通訊協定是由 Apple 所提出的, 現在雖然尚未成為 IETF 的標準, 但是因為主流的平臺, 諸如 iOS/Android 等重要的手持裝置平台, 皆已支援, 使得它已然成為業界標準(de-facto standard)了。

HTTP的基本運作原則, 就是一個請求可以取得一個檔案。倘若想要取得一個不知道長度有多長的檔案, 像即時的串流就是如此, 它很有可能不, 只是不知道有多長, 甚至不會有結束。過去, 有些人會基於HTTP做一些Hacks, 例如設一個非常大的檔案長度, 來表示一個即時的串流。但是, 有些多媒體檔案格式, 在串流內容還沒結束時, 形同檔案沒有完成, 接收端也可能無法正確的剖析及使用。

什麼是HLS? 簡單的來說, HLS就是一種基於HTTP協定之上的串流協定(參考WIKI)。HLS的核心想法, 是將串流的內容切割成一個個短的片段；例如, 如果是影音內容的話, 就把內容切割成約十秒左右的片段。不一定要切成十秒, 究竟要切成幾秒, 還可以考慮其他的因素。通常, 這十秒的片段的格式其容器（container）格式為MPEG-TS, 所包裝的視訊格式為H.264 , 而音訊格式為AAC。因此, 整個影音的內容，就會被切割成許許多多的小片段。

當支援 HLS 的播放器(player)要播放時，是從一個 .M3U8格式的播放清單開始，在這個播放清單中，會有一連串的MPEG-TS檔案的網址。此時，播放器只需要逐一的取出每個MPEG-TS檔案的網址，並且透過HTTP協定持續取得每一個MPEG-TS檔案，就能夠持續的播放整個串流的內容。

有一點很重要的是，在播放器播放某個MPEG-TS檔案的內容時，它可以取得整個清單中更後段的MPEG-TS檔案，預先下載儲存，這使得前一段播放完成時，下一段已經準備好了，因此可以達到流暢的播放。若是預儲的份量夠，則可以提供足夠的緩衝效果，來因應時有的網路傳輸速度短暫、不穩定情況。

正因為它是把整個串流的內容切割成多個小檔案，因此，得以實現即時的串流。

但說是即時，也不那麼的完全即時。因為，整個內容來源就算很快的完成格式的轉換、壓縮、及切割，客戶端也要載入起碼一個MPEG-TS，之後才能播放，也就是說，起碼也要再等10秒（若是單一個MPEG-TS切割成10秒的話），才能看到直播的內容。但是，絕大多數的應用情境，都可以接受一定程度的直播延遲，這使得HLS有機會成為網路串流直播的主要選項。

當初HLS選擇基於HTTP是個不錯的決定，怎麼說呢？第一個考量是，HTTP是一個「穿透率」比較好的協定，因為它是瀏覽網站時所需的協定，因此，許多防火牆都會開放HTTP通過。倘若是其他的串流協定，不見得就會出現在防火牆的開放清單中。

首先，HLS通過使用區塊(Chunks)載入來解決緩衝這個問題；其次，HLS 降低了傳送內容的成本。使用大家能接受 HTTP 協議，內容所有者可以很輕易地將其內容提供給線上觀眾，並擴大潛在的收視率。 HLS普及率也是很高的，支持和提供給更多的設備與玩家，這意味著觀眾無需專門的設備就可以隨意觀看HLS輸出內容。無論您是使用 iOS、Android、HTML5 播放器甚至是某些機上盒都可以使用HLS串流。

最後，HLS 與 MPEG-DASH（Dynamic Adaptive Streaming over HTTP基於HTTP的動態自適應流媒體）標準一樣，基於清單式(Manifest)HLS使用分組內容分發模型(.m3u8)文件剪切並重新組合視頻塊。同時它還為CDN 和編碼/轉碼軟體提供商提供了一個相對通用的平台，以在其基礎架構中進行標準化，並允許基於邊緣式(edge-based)的自適應比特率（ABR）轉碼。