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)轉碼。