瞎扯

談到音視頻方向的不可避免的談到采集、前處理，編碼、傳輸、存儲、解碼、后處理、顯示；作為一個整體向用戶提供時，性能、服務質量是最重要的標準，但是這里不談論整體的性能、服務質量，我們談論下傳輸相關的常見的問題和解決方案。其他步驟如何衡量都有專門的標準，不是這里要談論的。

這里的傳輸是泛指不單單指網絡傳輸，但是我們這里確單單只談論公網傳輸，因為公網傳輸是最復雜的場景，其他傳輸可以參考網絡傳輸。

網絡傳輸現在最出名的應該是QUIC了，這個協議已經被納入了http3標準；但是這些文章有很多，我們還不談。

網絡傳輸本質

圖1表明數據產生速度和網速相等，這個時候是最佳狀態，盡可能完整的發送更多的數據。

圖2表明數據產生的速度大于網絡速度，這個時候會出現網絡擁塞，出現丟包、亂序；都是無法及時、可靠的傳給對端的（這個時候有同學說TCP可以可靠傳輸，但是無法及時；UDP可以快速但是無法可靠）

圖3表明數據產生的速度小于網絡速度，這個時候網絡不會擁塞，我們大部分都是要解決的是這種場景下的丟包、亂序問題。

結論

分析上面三個圖可以得出這個結論，如果網絡小于數據產生/消耗速度；生產側出現數據積攢，數據無法及時發出；播放側會出現卡頓；這個是必然，但是我們怎么知道網速是多少啊，老板一問傻眼了！？下面談論是如何合理的懟老板的方法。

數據說話

先說定義，再說數字！

先說定義，再說數字！

先說定義，再說數字！

先說不好的，但是我經常看優愛騰天天說自己成功率99%以上，但是我一直是1%的人；他們定義的99%是對外的指標，但是實際指標只有自己清楚，舉例說明：

一個不存在的資源播放了對于播放器團隊肯定把這個當成噪點過濾，不算自己失敗；但是對用戶來說是個失敗啊！

一個播放中間忽然網絡卡頓了，沒法繼續播放了，原因未知，但是這種情況一般沒有人統計，但是對于用戶也是個失敗！

如果老板問一些很傻的問題，上面人家這種統計方式忽悠老板完全沒問題；他們可以很有理由的說我們統計是99%成功率，然后老板問那1%失敗是啥原因啊，他們說CDN資源不存在占比20%，網絡不好用戶沒有沒有播放出來就停止了70%，還有10%的情況未知，就這么忽悠老板結束了；哎，沒辦法，互聯網浮躁啊，沒有真正對用戶負責的太可怕了。（小公司的機會）

真正的數據埋點應該是從用戶體驗埋點，然后再分開埋各個模塊的點，如果用戶體驗收到的影響可以追蹤到那個模塊出了問題；本著這個原則，網絡如何埋點呢？!?

丟包：丟包的總數、最大連續丟包個數、最小連續丟包個數；分別統計1s 5s 10s

亂序：亂序總次數，最大的亂序次數，最小的亂序次數；分別統計1s 5s 10s

RTT：平均RTT，最大的RTT，最小的RTT，分別統計1s 5s 10s

我們在傳輸的時候也會加入NACK、FEC；這個時候還要統計FEC包數、恢復的包數、NACK包數，恢復的包數；丟包就要統計恢復后的丟白、恢復前的丟包。當我們把這些數據擺在面前的時候，老板還有什么話說呢！？但是如果這些沒問題，但是用戶還是反饋體驗太差，這個時候就不是網絡傳輸問題，要從自身查找問題了，

網絡抖動一下你的系統都扛不住說不過去吧？

網絡抖動你恢復的特別慢說不過去吧？

帶寬大于數據但是還是卡成屎說不過去吧？

音視頻不同步說不過去吧？

人家cpu20%，你非要30%說不過去吧？

渲染有鋸齒說不過去吧？

沒有美顏說不過去吧？long-fat網絡咋辦？

brust丟包咋辦？

用你的音視頻系統包太大說不過去吧？

問題一大堆，總之demo距離工程還有1w個webrtc。

總結

以上是生活随笔為你收集整理的浅谈音视频网络传输的全部內容，希望文章能夠幫你解決所遇到的問題。

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