直播和互動直播在2017年引起了人們的極大關注，應運而生的各種直播類APP多如牛毛。隨著互動直播的逐漸興起，互動成為直播APP的強需求。然而，實際網路中的丟包、延遲、抖動等問題仍然嚴重影響了直播的效果。
針對上述問題，本文介紹了網易雲信直播的網路QoS技術，旨在幫助讀者瞭解在極差網路環境下如何最大限度的保障直播的流暢性和清晰度。
相關閱讀推薦
流暢性和清晰度定義
觀眾在觀看直播或者與主播進行互動直播的過程中，對音視訊流暢性和清晰度的感受可以通過視訊幀率、視訊PSNR（或SSIM）分值、音訊MOS分值等客觀引數指標來表徵。越高的視訊幀率帶來的視訊流暢性越高，越高的視訊PSNR（或SSIM）分值帶來的視訊清晰度越高，越高的音訊MOS分值帶來的音訊流暢性和清晰度越高。
那麼，如何通過提高網路QoS技術改善網路質量，從而提高上述的客觀指標呢？下面我們就單向直播和互動直播分別進行介紹。
單向直播的流暢性和清晰度
這裡的單向直播特指通過RTMP/TCP協議將音視訊流推送到CDN，然後觀眾拉流觀看的一種直播方式。
眾所周知，TCP是一個面向連線的傳輸層協議，協議本身保證了傳輸的可靠性。通過呼叫開源框架librtmp，開發者可以非常容易的實現RTMP推流服務。然而，在網路出現丟包和抖動的時候，TCP的擁塞控制策略會限制推流端的傳送位元速率，使得觀眾端出現突發的拉流卡頓，影響音視訊的流暢性。
通常情況下，應對網路丟包的策略有前向錯誤隱藏（FEC）、音訊RED冗餘、重傳等，應對網路頻寬受限有音視訊的自適應位元速率調節策略。考慮到TCP協議的特殊性，我們無法設計靈活的重傳和自適應位元速率調節策略，資料傳送的多少和頻率完全由TCP協議本身控制。這種情況下，我們可以做的是及時有效的檢測網路可用頻寬，並調節音視訊編碼器的輸出位元速率，做到位元速率自適應。
具體的實現方法是，通過平臺（ios、Android或者Windows）相關的TCP socket介面獲取網路資訊，感知網路擁塞，估算得到可用頻寬，及時調節音視訊編碼器的設定位元速率，防止音視訊卡頓發生，保證流暢性。
互動直播的流暢性和清晰度
這裡的互動直播特指連麥者通過RTP/UDP協議將音視訊流推送到中轉伺服器，進行混流後再通過RTMP/TCP協議推送到CDN，然後觀眾拉流觀看的直播方式。
UDP不同於TCP，協議本身不關心資料是否及時可靠到達對端，只是完成“傳送”的操作。由此，我們可以採用種類繁多的技術手段保證UDP協議資料的可靠達到。例如：前向錯誤隱藏（FEC）、音訊RED冗餘、重傳等策略。根據網路狀況和媒體資料的不同，我們採取相應的策略。
按照如下的技術分別介紹：
頻寬估計
頻寬估計的作用是準確的獲得當前的可用網路頻寬，進而指導音視訊編碼器的頻寬分配，使得實際傳送位元速率不超過可用頻寬，從而不會引起延時增加和丟包。常用的頻寬估計方法包括根據丟包或者延遲變化估計頻寬，Google的WebRTC中就包含了完整的頻寬估計方法，值得大家學習借鑑。
錯誤隱藏
當接收端收到的音視訊資料已經發生了丟失，我們該如何恢復資料呢？從音視訊解碼的角度看，可以通過視訊（音訊）前一幀或者多幀資料恢復丟失的資料。然而，常用的視訊錯誤隱藏方法往往會對恢復的影像造成馬賽克現象，錯誤隱藏的效果不佳。所以大多數情況不採用這類錯誤隱藏技術，而是解碼之前會判斷一幀資料是否完整，完整的資料才會被送入解碼器，不完整的資料直接丟棄。音訊領域的錯誤隱藏是另一種情況，音訊的錯誤隱藏技術要普遍優於視訊的錯誤隱藏，流行的音訊壓縮標準Opus、iLBC、iSAC/SILK等，都含有自己的PLC（Packet Loss Concealment）模組，解碼器在檢測到丟幀的時候會自動進行錯誤隱藏，實際效果還可以接受。
前向糾錯
前向糾錯技術相當於在傳送端多發一部分資料，這部分資料可能是原始資料的複本，也可能是多份原始資料相互計算的結果。如果原始資料在傳輸過程中發生了丟失，那麼這部分冗餘資料就可以發揮作用，幫助恢復丟失的原始資料。當然了，這種策略犧牲的是有限的網路頻寬。
視訊資料區別於音訊資料的一個特點是，視訊的資料包較大，一般情況會接近MTU大小，同時觀眾對視訊資料的端到端延遲不如音訊資料敏感。因此可以採用數目較大的FEC分組進行前向糾錯。而音訊資料包較小，資料包頭在整個資料包中的佔比相對視訊要高出很多，所以進行RED冗餘能夠使多個音訊包複用同一個包頭，提高資料利用率。另一方面，如果音訊資料採用FEC進行前向糾錯，勢必會增加延遲，影響通話體驗。
因此，視訊資料較適宜採用FEC技術進行前向糾錯，音訊資料較適宜採用RED技術進行冗餘操作。
重傳
除了前向糾錯技術，在網路RTT較小的時候，我們也可以向傳送端請求網路中丟失的資料包，這就是重傳技術。這個技術適用於網路RTT較小的情況，相比於FEC和RED，重傳可以大幅提高頻寬利用率，做到“丟哪個包要哪個包”，有針對性的重傳丟失的資料包。
考慮到觀眾對音訊資料的敏感性，除非網路RTT很小，否則音訊一般不採用重傳技術。視訊較多采用重傳技術進行錯誤恢復，根據重傳請求資料的不同又分為I幀請求和資料包請求。
I幀請求是當接收端無法繼續解碼，而且傳送端的GOP長度又很長的時候，需要及時請求傳送端傳送I幀，使得接收端根據這個I幀可以儘快恢復顯示。資料包請求則是根據丟失的資料包，向傳送端有針對性的請求，這種情況下傳送端需要快取已經發出去的資料包，以備後續接收端的請求。
以上簡單介紹了直播中提高流暢性和清晰度的幾種方法和策略。實際使用中還需要考慮多種技術的有機結合，以及伺服器端與客戶端的相互配合，並結合使用者使用場景和客戶端裝置效能等因素綜合考慮。
另外，想要獲取更多產品乾貨、技術乾貨，記得關注網易雲信部落格。