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

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

HTTP流式傳輸相關參考文檔：

又拍云直播協議HTTP-FLV詳解

一、基本介紹

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

二、開發過程中的改進點

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

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

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

關于安全性

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

客戶端的支持

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

關于P2P

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。