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

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

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

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

一、基本介紹

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

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

直播過程中的累積延遲消除

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

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

關(guān)于安全性

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

客戶端的支持

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

關(guān)于P2P

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

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

總結(jié)

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

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