hls協(xié)議是什么_hls協(xié)議詳細(xì)介紹
掃描二維碼
隨時(shí)隨地手機(jī)看文章
HLS常用的流媒體協(xié)議主要有 HTTP 漸進(jìn)下載和基于 RTSP/RTP 的實(shí)時(shí)流媒體協(xié)議，這二種基本是完全不同的東西，目前比較方便又好用的是用 HTTP 漸進(jìn)下載方法。在這個(gè)中 apple 公司的 HTTP Live Streaming 是這個(gè)方面的代表。它最初是蘋(píng)果公司針對(duì)iPhone、iPod、iTouch和iPad等移動(dòng)設(shè)備而開(kāi)發(fā)的流?，F(xiàn)在見(jiàn)到在桌面也有很多應(yīng)用了，HTML5 是直接支持這個(gè)。
但是HLS協(xié)議的小切片方式會(huì)生成大量的文件，存儲(chǔ)或處理這些文件會(huì)造成大量資源浪費(fèi)。如果要實(shí)現(xiàn)數(shù)天的時(shí)移，索引量將會(huì)是個(gè)巨額數(shù)字，并明顯影響請(qǐng)求速度。因此，HLS協(xié)議對(duì)存儲(chǔ)I/O要求相當(dāng)苛刻。對(duì)此，也有公司提出了非常好的解決方案。
新型點(diǎn)播服務(wù)器系統(tǒng)，獨(dú)創(chuàng)了內(nèi)存緩存數(shù)據(jù)實(shí)時(shí)切片技術(shù)，顛覆了這種傳統(tǒng)實(shí)現(xiàn)方法，從根本上解決了大量切片的碎片問(wèn)題，使得單臺(tái)服務(wù)器的切片與打包能力不再是瓶頸。其基本原理如下：
不將TS切片文件存到磁盤(pán)，而是存在內(nèi)存當(dāng)中，這種技術(shù)使得服務(wù)器的磁盤(pán)上面不再會(huì)有“數(shù)以噸計(jì)”的文件碎片，極大減少了磁盤(pán)的I/O次數(shù)，延長(zhǎng)了服務(wù)器磁盤(pán)的使用壽命，極大提高了服務(wù)器運(yùn)行的穩(wěn)定性。同時(shí)，由于使用這種技術(shù)，使得終端請(qǐng)求數(shù)據(jù)時(shí)直接從服務(wù)器的內(nèi)存中獲取，極大提高了對(duì)終端數(shù)據(jù)請(qǐng)求的反應(yīng)速度，優(yōu)化了視頻觀看體驗(yàn)。
HTTP Live Streaming（縮寫(xiě)是HLS）是一個(gè)由蘋(píng)果公司提出的基于HTTP的流媒體網(wǎng)絡(luò)傳輸協(xié)議。是蘋(píng)果公司QuickTIme X和iPhone軟件系統(tǒng)的一部分。它的工作原理是把整個(gè)流分成一個(gè)個(gè)小的基于HTTP的文件來(lái)下載，每次只下載一些。當(dāng)媒體流正在播放時(shí)，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會(huì)話適應(yīng)不同的數(shù)據(jù)速率。在開(kāi)始一個(gè)流媒體會(huì)話時(shí)，客戶端會(huì)下載一個(gè)包含元數(shù)據(jù)的extended M3U （m3u8）playlist文件，用于尋找可用的媒體流。
HLS只請(qǐng)求基本的HTTP報(bào)文，與實(shí)時(shí)傳輸協(xié)議（RTP）不同，HLS可以穿過(guò)任何允許HTTP數(shù)據(jù)通過(guò)的防火墻或者代理服務(wù)器。它也很容易使用內(nèi)容分發(fā)網(wǎng)絡(luò)來(lái)傳輸媒體流。
蘋(píng)果公司把HLS協(xié)議作為一個(gè)互聯(lián)網(wǎng)草案（逐步提交），在第一階段中已作為一個(gè)非正式的標(biāo)準(zhǔn)提交到IETF。但是，即使蘋(píng)果偶爾地提交一些小的更新，IETF卻沒(méi)有關(guān)于制定此標(biāo)準(zhǔn)的有關(guān)進(jìn)一步的動(dòng)作。
HLS協(xié)議簡(jiǎn)介HLS協(xié)議規(guī)定：
視頻的封裝格式是TS。
視頻的編碼格式為H264，音頻編碼格式為MP3、AAC或者AC-3。
除了TS視頻文件本身，還定義了用來(lái)控制播放的m3u8文件（文本文件）。
為什么蘋(píng)果要提出HLS這個(gè)協(xié)議，其實(shí)他的主要是為了解決RTMP協(xié)議存在的一些問(wèn)題。比如RTMP協(xié)議不使用標(biāo)準(zhǔn)的HTTP接口傳輸數(shù)據(jù)，所以在一些特殊的網(wǎng)絡(luò)環(huán)境下可能被防火墻屏蔽掉。但是HLS由于使用的HTTP協(xié)議傳輸數(shù)據(jù)，不會(huì)遇到被防火墻屏蔽的情況（該不會(huì)有防火墻連80接口都不放過(guò)吧）。
另外于負(fù)載，RTMP是一種有狀態(tài)協(xié)議，很難對(duì)視頻服務(wù)器進(jìn)行平滑擴(kuò)展，因?yàn)樾枰獮槊恳粋€(gè)播放視頻流的客戶端維護(hù)狀態(tài)。而HLS基于無(wú)狀態(tài)協(xié)議（HTTP），客戶端只是按照順序使用下載存儲(chǔ)在服務(wù)器的普通TS文件，做負(fù)責(zé)均衡如同普通的HTTP文件服務(wù)器的負(fù)載均衡一樣簡(jiǎn)單。
另外HLS協(xié)議本身實(shí)現(xiàn)了碼率自適應(yīng)，不同帶寬的設(shè)備可以自動(dòng)切換到最適合自己碼率的視頻播放。其實(shí)HLS最大的優(yōu)勢(shì)就是他的親爹是蘋(píng)果。蘋(píng)果在自家的IOS設(shè)備上只提供對(duì)HLS的原生支持，并且放棄了flash。Android也迫于平果的“淫威”原生支持了HLS。這樣一來(lái)flv，rtmp這些Adobe的視頻方案要想在移動(dòng)設(shè)備上播放需要額外下點(diǎn)功夫。當(dāng)然flash對(duì)移動(dòng)設(shè)備造成很大的性能壓力確實(shí)也是自身的問(wèn)題。
但HLS也有一些無(wú)法跨越的坑，比如采用HLS協(xié)議直播的視頻延遲時(shí)間無(wú)法下到10秒以下，而RTMP協(xié)議的延遲最低可以到3、4秒左右。所以說(shuō)對(duì)直播延遲比較敏感的服務(wù)請(qǐng)慎用HLS。
圖片來(lái)源于蘋(píng)果官網(wǎng)
來(lái)解釋一下這張圖，從左到右講，左下方的inputs的視頻源是什么格式都無(wú)所謂，他與server之間的通信協(xié)議也可以任意（比如RTMP），總之只要把視頻數(shù)據(jù)傳輸?shù)椒?wù)器上即可。這個(gè)視頻在server服務(wù)器上被轉(zhuǎn)換成HLS格式的視頻（既TS和m3u8文件）文件。細(xì)拆分來(lái)看server里面的Media encoder的是一個(gè)轉(zhuǎn)碼模塊負(fù)責(zé)將視頻源中的視頻數(shù)據(jù)轉(zhuǎn)碼到目標(biāo)編碼格式（H264）的視頻數(shù)據(jù)，視頻源的編碼格式可以是任何的視頻編碼格式（參考《視頻技術(shù)基礎(chǔ)》）。轉(zhuǎn)碼成H264視頻數(shù)據(jù)之后，在stream segmenter模塊將視頻切片，切片的結(jié)果就是index file（m3u8）和ts文件了。圖中的DistribuTIon其實(shí)只是一個(gè)普通的HTTP文件服務(wù)器，然后客戶端只需要訪問(wèn)一級(jí)index文件的路徑就會(huì)自動(dòng)播放HLS視頻流了。
HLS的index文件
所謂index文件就是之前說(shuō)的m3u8文本文件。
圖片來(lái)源于蘋(píng)果官網(wǎng)
如上圖所示，客戶端播放HLS視頻流的邏輯其實(shí)非常簡(jiǎn)單，先下載一級(jí)Index file，它里面記錄了二級(jí)索引文件（Alternate-A、Alternate-B、Alternate-C）的地址，然后客戶端再去下載二級(jí)索引文件，二級(jí)索引文件中又記錄了TS文件的下載地址，這樣客戶端就可以按順序下載TS視頻文件并連續(xù)播放。
一級(jí)index文件
視頻源：https://dco4urblvsasc.cloudfront.net/811/81095_ywfZjAuP/game/index.m3u8
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1，BANDWIDTH=1064000
1000kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1，BANDWIDTH=564000
500kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1，BANDWIDTH=282000
250kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1，BANDWIDTH=2128000
2000kbps.m3u8
bandwidth指定視頻流的比特率，PROGRAM-ID無(wú)用無(wú)需關(guān)注，每一個(gè)#EXT-X-STREAM-INF的下一行是二級(jí)index文件的路徑，可以用相對(duì)路徑也可以用絕對(duì)路徑。例子中用的是相對(duì)路徑。這個(gè)文件中記錄了不同比特率視頻流的二級(jí)index文件路徑，客戶端可以自己判斷自己的現(xiàn)行網(wǎng)絡(luò)帶寬，來(lái)決定播放哪一個(gè)視頻流。也可以在網(wǎng)絡(luò)帶寬變化的時(shí)候平滑切換到和帶寬匹配的視頻流。
#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXTINF:10，
2000kbps-00001.ts
#EXTINF:10，
2000kbps-00002.ts
#EXTINF:10，
2000kbps-00003.ts
#EXTINF:10，
2000kbps-00004.ts
#EXTINF:10，
。。. 。。.
#EXTINF:10，
2000kbps-00096.ts
#EXTINF:10，
2000kbps-00097.ts
#EXTINF:10，
2000kbps-00098.ts
#EXTINF:10，
2000kbps-00099.ts
#EXTINF:10，
2000kbps-00100.ts
#ZEN-TOTAL-DURATION:999.66667
#ZEN-AVERAGE-BANDWIDTH:2190954
#ZEN-MAXIMUM-BANDWIDTH:3536205
#EXT-X-ENDLIST
二級(jí)文件實(shí)際負(fù)責(zé)給出ts文件的下載地址，這里同樣使用了相對(duì)路徑。#EXTINF表示每個(gè)ts切片視頻文件的時(shí)長(zhǎng)。#EXT-X-TARGETDURATION指定當(dāng)前視頻流中的切片文件的最大時(shí)長(zhǎng)，也就是說(shuō)這些ts切片的時(shí)長(zhǎng)不能大于#EXT-X-TARGETDURATION的值。#EXT-X-PLAYLIST-TYPE:VOD的意思是當(dāng)前的視頻流并不是一個(gè)直播流，而是點(diǎn)播流，換句話說(shuō)就是該視頻的全部的ts文件已經(jīng)被生成好了，#EXT-X-ENDLIST這個(gè)表示視頻結(jié)束，有這個(gè)標(biāo)志同時(shí)也說(shuō)明當(dāng)前的流是一個(gè)非直播流。
播放模式
點(diǎn)播VOD的特點(diǎn)就是當(dāng)前時(shí)間點(diǎn)可以獲取到所有index文件和ts文件，二級(jí)index文件中記錄了所有ts文件的地址。這種模式允許客戶端訪問(wèn)全部?jī)?nèi)容。上面的例子中就是一個(gè)點(diǎn)播模式下的m3u8的結(jié)構(gòu)。
Live 模式就是實(shí)時(shí)生成M3u8和ts文件。它的索引文件一直處于動(dòng)態(tài)變化的，播放的時(shí)候需要不斷下載二級(jí)index文件，以獲得最新生成的ts文件播放視頻。如果一個(gè)二級(jí)index文件的末尾沒(méi)有#EXT-X-ENDLIST標(biāo)志，說(shuō)明它是一個(gè)Live視頻流。
客戶端在播放VOD模式的視頻時(shí)其實(shí)只需要下載一次一級(jí)index文件和二級(jí)index文件就可以得到所有ts文件的下載地址，除非客戶端進(jìn)行比特率切換，否則無(wú)需再下載任何index文件，只需順序下載ts文件并播放就可以了。但是Live模式下略有不同，因?yàn)椴シ诺耐瑫r(shí)，新ts文件也在被生成中，所以客戶端實(shí)際上是下載一次二級(jí)index文件，然后下載ts文件，再下載二級(jí)index文件（這個(gè)時(shí)候這個(gè)二級(jí)index文件已經(jīng)被重寫(xiě)，記錄了新生成的ts文件的下載地址），再下載新ts文件，如此反復(fù)進(jìn)行播放。
HLS 的請(qǐng)求流程是：
1 http 請(qǐng)求 m3u8 的 url。
2 服務(wù)端返回一個(gè) m3u8 的播放列表，這個(gè)播放列表是實(shí)時(shí)更新的，一般一次給出5段數(shù)據(jù)的 url。
3 客戶端解析 m3u8 的播放列表，再按序請(qǐng)求每一段的 url，獲取 ts 數(shù)據(jù)流。
簡(jiǎn)單流程：
下載文檔
