綜述的協(xié)議對(duì)比，可以參考不同音視頻傳輸協(xié)議的對(duì)比

比如現(xiàn)在常見的移動(dòng)端互動(dòng)直播，常使用HTTP-flv方式在網(wǎng)絡(luò)上傳輸。使用flv極為簡(jiǎn)單的封裝格式，再疊加http良好的網(wǎng)絡(luò)兼容性，另外播放延遲和首幀時(shí)間也有較好的保證。

HTTP流式傳輸相關(guān)參考文檔：

又拍云直播協(xié)議HTTP-FLV詳解

一、基本介紹

• 1)HTTP-FLV是一個(gè)非常民間的說(shuō)法，反正也沒啥很官方的文檔。一般叫做FLV over HTTP, 通常說(shuō)的http progressive streaming(也因?yàn)椴⒉皇钦嬲牧魇絺鬏敹环Q為progressive download)
• 2)progressive streaming和real streaming之間的差別是——看起來(lái)都是流式傳輸播放。progressive streaming實(shí)際上是一種將整個(gè)直播數(shù)據(jù)虛擬成一個(gè)巨大的flv文件，從服務(wù)端漸進(jìn)地下載緩存小分片文件來(lái)模擬流式傳輸?shù)姆绞?#xff0c;也就是說(shuō)服務(wù)端將音視頻數(shù)據(jù)封裝為一個(gè)個(gè)小分片（在http-flv中就是一個(gè)個(gè)flv tag)，然后客戶端通過(guò)HTTP請(qǐng)求下載到這些數(shù)據(jù)，緩存在本地然后播放，服務(wù)端只需要是HTTP服務(wù)器即可，不夠安全。而真正的流式傳輸是像RTMP協(xié)議那樣，建立了一個(gè)與服務(wù)端的長(zhǎng)連接，服務(wù)端一有數(shù)據(jù)就實(shí)時(shí)轉(zhuǎn)發(fā)，對(duì)服務(wù)端要求較高，比較安全。
• 3)個(gè)人覺得在互動(dòng)直播播放端的話，除了對(duì)版權(quán)要求很高的場(chǎng)景或者要求碼率自適應(yīng)，實(shí)在想不到有什么原因要棄用HTTP-FLV。
• 4)http-flv的技術(shù)點(diǎn)就是——基本都是很成熟通用的技術(shù)，包括http服務(wù)器，flv tag的封裝，播放flv數(shù)據(jù)。
• 5)HTTP progressive download和hls之類的差別——都是基于HTTP，都是服務(wù)端切成了一個(gè)個(gè)小分片，那怎么理解？（個(gè)人理解，錯(cuò)誤請(qǐng)拍磚）除去hls的碼率自適應(yīng)特征，首先http-flv并不是一種物理上的切片文件，實(shí)際上服務(wù)端最終存儲(chǔ)的仍舊是一個(gè)大文件（不過(guò)是容量體積不斷增長(zhǎng)的大文件），而hls卻實(shí)實(shí)在在地將音視頻數(shù)據(jù)封裝在不同的物理分片中（服務(wù)端如果不及時(shí)清理，就會(huì)有大量的細(xì)碎文件存在）。http-flv中提到的分片只是整個(gè)大文件中的一段，拿出來(lái)無(wú)法獨(dú)立解碼播放，需要依賴最開始請(qǐng)求的metadata，而ts是可以獨(dú)立解碼播放的。通常來(lái)說(shuō)http-flv提到的分片都很小，而hls中的切片比較大，這就導(dǎo)致了hls很嚴(yán)重的延遲問題。

二、開發(fā)過(guò)程中的改進(jìn)點(diǎn)

直播過(guò)程中的累積延遲消除

會(huì)有專門的文檔提到如何處理延遲，這里簡(jiǎn)單提一下。由于依賴可靠傳輸，播放過(guò)程中難免會(huì)出現(xiàn)延遲逐漸增大的情況，這顯然是互動(dòng)直播無(wú)法接受的。客戶端播放http-flv時(shí)可以采用丟幀策略和抖動(dòng)緩沖。

• 丟幀策略 丟幀就是按照字面的理解，解碼播放過(guò)程中丟棄一些幀。丟哪些幀/關(guān)鍵幀還是僅非關(guān)鍵幀/視頻幀還是音頻幀/用什么頻率和策略來(lái)丟幀？這些可以單獨(dú)寫一篇文章了。。。總之就是基于不花屏不變聲，也不嚴(yán)重跳播的前提下平滑丟幀。
• 抖動(dòng)緩沖 抖動(dòng)緩沖其實(shí)還是為了適應(yīng)網(wǎng)絡(luò)環(huán)境及減小延遲，比如當(dāng)網(wǎng)絡(luò)變差或切換網(wǎng)絡(luò)的時(shí)候（腫么破，根本下不到新的數(shù)據(jù)啊），這時(shí)候顯然要把延遲的優(yōu)先級(jí)降低，用已緩沖的數(shù)據(jù)來(lái)保證播放，而如果網(wǎng)絡(luò)良好或者從較差網(wǎng)絡(luò)中恢復(fù)，一下子從服務(wù)端下載到很多的數(shù)據(jù)了，也不用擔(dān)心會(huì)卡頓了，這時(shí)候可以提高延遲的優(yōu)先級(jí)，減少緩沖數(shù)據(jù)。

關(guān)于安全性

好像除了在建立連接的時(shí)候，加一些鑒權(quán)，暫時(shí)也沒想到什么合適的辦法。

客戶端的支持

android和ios端觀看互動(dòng)直播的需求比較多，如果使用通用的軟解碼方式，可以統(tǒng)一雙端播放內(nèi)核，減少開發(fā)量。但是弊端也比較明顯，一般軟解的效率都比硬解要差一些。如果考慮到解碼效率，決定選擇硬解的話，需要客戶端先將數(shù)據(jù)解封裝成H264/AAC裸數(shù)據(jù)，然后再送入解碼器，就不能直接調(diào)用系統(tǒng)上層封裝的解碼接口了。

關(guān)于P2P

相比起rtmp的封閉性來(lái)說(shuō)，http-flv傳輸中客戶端的P2P至少是可以實(shí)現(xiàn)的。但會(huì)要求客戶端多緩沖一些數(shù)據(jù)。

作者：littleRabbit
鏈接：https://juejin.im/post/5a6882aaf265da3e5033ef4d
來(lái)源：掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

總結(jié)

以上是生活随笔為你收集整理的HTTP progressive download渐进式传输的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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