直播未來(lái)屬于RTMP還是HTTP？

HTTP 傳視頻比 RTMP 實(shí)現(xiàn)起來(lái)簡(jiǎn)單？HTTP 延遲太高？

答：直播通訊未來(lái)是屬于html5的。

?

1，協(xié)議使用份額

如今國(guó)內(nèi)90%的面向大眾的直播平臺(tái)都是采用的rtmp和httpflv的混合，hls很少，而國(guó)外大部分采用的dash，少部分用hls和其他協(xié)議。

2，先簡(jiǎn)單的描述下這些協(xié)議

httpflv：這種直播傳輸實(shí)際上就是利用的flv文件的特點(diǎn)，只需要一個(gè)matedata和音視頻各自header，后面的音視頻數(shù)據(jù)就可以隨意按照時(shí)間戳傳輸，當(dāng)然視頻得按照gop段來(lái)傳輸，這種直播數(shù)據(jù)實(shí)際上就是一個(gè)無(wú)限大的http傳輸?shù)膄lv文件，視頻地址類似：

http://mywebsite.com/live.flv，客戶端利用flv特性，可以一邊接受數(shù)據(jù)邊解碼播放。

rtmp：rtmp是adobe研發(fā)的開(kāi)放協(xié)議，rtmp其實(shí)實(shí)質(zhì)上也是傳輸?shù)膄lv格式的數(shù)據(jù)，同樣是flv tag，只不過(guò)rtmp在傳輸上封裝了一層，比如rtmp不僅可以直播，也可以推流。rtmp的直播原理同樣也是利用了flv文件的特性，只需要一些頭信息，后面就可以隨意傳輸音視頻數(shù)據(jù)，達(dá)到邊傳輸邊播放。

hls：hls是蘋果公司開(kāi)發(fā)的協(xié)議，http輪詢傳輸，該協(xié)議主要的數(shù)據(jù)格式是ts視頻文件，大致就是將裸流h264和音頻直播數(shù)據(jù)，切片封裝成ts段，形成無(wú)數(shù)的ts小文件，客戶端先請(qǐng)求一個(gè)m3u8文件，該文件內(nèi)部會(huì)有一列ts文件的地址，客戶端按照順序依次播放ts，以此類推，hls地址類似：http://mywebsite.com/live.m3u8，hls在大部分的瀏覽器利用html5video是可以直接播放的。

?

dash：這個(gè)協(xié)議國(guó)內(nèi)用的不多，http輪詢傳輸，但是國(guó)外很多平臺(tái)都在用，比如youtube直播，該協(xié)議是google公司研發(fā)的，和hls如出一轍，同樣是將直播流數(shù)據(jù)切片，只不過(guò)不是ts文件，而是mp4或者3gp文件，又或者webm（vp8，vp9）文件，該協(xié)議同樣和hls一樣也是http傳輸，同樣和hls主打的是“自適應(yīng)動(dòng)態(tài)碼率”，大概意思就是當(dāng)客戶端網(wǎng)絡(luò)不好的時(shí)候會(huì)無(wú)縫切換到低碼率的路線。

3，各種協(xié)議延時(shí)及其原因

rtmp和httpflv：這兩種協(xié)議大致數(shù)據(jù)一致，所以延時(shí)原因都是差不多的。按理說(shuō)tcp流式傳輸直播因該都是延時(shí)極低的，為什么rtmp和httpflv還有延時(shí)呢？原因在h264上，rtmp和httpflv都是傳輸?shù)膄lv tag，視頻tag的數(shù)據(jù)平常就是h264數(shù)據(jù)，h264解碼有個(gè)IBP，I是關(guān)鍵幀，是一幀完整的圖像，必須要先有個(gè)I才能解碼后面的BP，BP幀可以隨便少，但是I幀不能少，所以I幀必須是在flv tag傳輸中第二個(gè)傳輸?shù)?#xff08;第一個(gè)是h264spspps），但是I幀在h264流里不是常有的，是隔一段才有個(gè)I幀，這個(gè)一段的間隔，俗稱GOP，當(dāng)編碼時(shí)候GOP設(shè)置很短，當(dāng)客戶端連接上來(lái)，服務(wù)器會(huì)以最快速度找到流中最近I幀，從I幀開(kāi)始發(fā)送直播數(shù)據(jù)，然而當(dāng)GOP很長(zhǎng)，I幀間隔很長(zhǎng)，或者等待下一個(gè)I幀開(kāi)始向新連接發(fā)送數(shù)據(jù)，或者在緩存里找最近的上一個(gè)I幀開(kāi)始發(fā)送，這里就是rtmp和hls協(xié)議延時(shí)的關(guān)鍵了，在各大cdn平臺(tái)，叫“rtmp秒開(kāi)技術(shù)”，原理就是將推流數(shù)據(jù)二次解編碼，設(shè)置很小的gop。總的來(lái)說(shuō)，gop設(shè)置1s，在不考慮網(wǎng)絡(luò)傳輸鏈路延時(shí)情況，數(shù)據(jù)延時(shí)最大就為1s，運(yùn)氣好剛好就是I幀就是0延時(shí)！

hls和dash：這兩種協(xié)議延時(shí)原因大致都是差不多的，因?yàn)榍衅?#xff0c;切成小端的文件，單獨(dú)開(kāi)始傳輸，這就是延時(shí)的關(guān)鍵了，當(dāng)然可以設(shè)置切成小文件，越小延時(shí)越低。按理說(shuō)dash切片要比hls稍微先進(jìn)一點(diǎn)，所以延時(shí)上dash要比hls低，但是同樣的，切片了，就注定延時(shí)。

4，關(guān)于解碼播放的優(yōu)劣勢(shì)

首先，我想說(shuō)flash真的要被淘汰了，rtmp和httpflv目前在網(wǎng)頁(yè)上只能用flash或者插件的方式解碼播放，而且flash在cpu和內(nèi)存上都是占用很高。但是在客戶端app上，不用網(wǎng)頁(yè)播放，你可以不用擔(dān)心這個(gè)問(wèn)題。網(wǎng)頁(yè)上播放，hls和dash的優(yōu)勢(shì)就體現(xiàn)出來(lái)了，可以用html5直接播放，當(dāng)然理論上，dash的mp4的兼容性要比hls更好。而且hls和dash支持動(dòng)態(tài)適應(yīng)網(wǎng)絡(luò)，無(wú)縫調(diào)節(jié)碼率，這在網(wǎng)絡(luò)波動(dòng)很大的地方，這個(gè)功能不錯(cuò)，當(dāng)然個(gè)人對(duì)于這個(gè)功能無(wú)所謂，我情愿線下看高清，也不線上看馬賽克。

5，總結(jié)

對(duì)于各種面向用戶的直播協(xié)議，我只講了一部分的，當(dāng)然還有更多，這里就不一一列舉了。以后在瀏覽器上肯定是html5的市場(chǎng)，無(wú)論是hls也好dash也罷，或者新興的很多websocket直播也好，技術(shù)反正是在不斷更替的，或許有天，html5突然支持flv播放了呢？

我列一個(gè)表作為總結(jié)：

協(xié)議	httpflv	rtmp	hls	dash
傳輸層	http流	tcp流	http	http
視頻格式	flv	flv tag	Ts文件	Mp4 3gp webm
延時(shí)	低	低	很高	高
數(shù)據(jù)分段	連續(xù)流	連續(xù)流	切片文件	切片文件
Html5播放	暫不支持	不支持	大部分支持	極大部分支持
服務(wù)器編程難易	簡(jiǎn)單	一般	一般+	中等

總結(jié)

以上是生活随笔為你收集整理的直播未来属于RTMP还是HTTP？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。