轉自：http://www.aiweibang.com/m/detail/104476372.html?from=p
隨着WebRTC標准的逐步推廣，實時音視頻通訊技術受到越來越多公司和技術人員的關注。對於交互式音視頻應用而言，穩定、低延時、通話質量清晰可靠是其基本需求。在互聯網環境下，音視頻的通話質量與以下因素有關：一是編碼碼率、幀率和分辨率等編碼因素；二是網絡的接入類型和接入設備性能；三是對丟包、抖動、亂序以及網絡擁塞的自適應調整能力，即QoS（Quality of Service，服務質量）。容聯雲通訊是國內最早且通訊能力最全的PaaS服務商，在推出音視頻通話這一關鍵能力時，更加注重保證QoS（Quality of Service，服務質量），提升用戶體驗。本文主要介紹為保證QoS，在音視頻傳輸和處理過程中采用的關鍵技術。
交互式實時視頻應用通常采用RTP協議進行音視頻傳輸，RTP頭部提供了諸如負載類型、時間戳、序列號和同步源等信息保證基本的音視頻傳輸需求。但與TCP不同，RTP協議底層采用不可靠的UDP傳輸層協議，當網絡過載或擁塞，無法實現對丟包、抖動、亂序以及網絡擁塞的自適應調整。與音頻相比，視頻傳輸由於所占的帶寬更大，更易受到網絡環境變化的影響，因此以下將以視頻為例分析Qos提升途徑。
一、處理丟包
對與實時視頻來說，網絡出現丟包將直接導致接收端畫面出現馬賽克和花屏。有多種策略可以解決，包括：基於NACK反饋的丟包重傳，前向糾錯FEC和參考幀選擇RPS，這些策略通常與編解碼端的容錯技術（如：幀內刷新和錯誤隱藏）配合使用。
基於NACK反饋的丟包重傳方法：接收端循環檢查接收緩沖，當發現丟包后使用RTCP NACK反饋報文將丟包信息反饋給發送端；發送端接收NACK反饋並解析后從發送緩存取出對應RTP包，並再次發送給接收端。該方法的缺點是增大了端到端的延遲，尤其在丟包大量發生時更為明顯。
前向糾錯FEC：FEC機制是在接收端根據視頻幀的重要性（參考幀或非參考幀）發送冗余的視頻RTP包，在接收端如果檢測到丟包則利用冗余包進行恢復，否則將冗余包丟棄。該方法的優點是視頻無延遲，但發送冗余包占用了額外的帶寬資源。
更為可行的方案是是混合NACK／FEC模式，接收端根據幀大小和接收時延估計可用帶寬，發送端根據可用帶寬、丟包和RTT等反饋計算分配保護開銷（protection overhead，包括FEC bitrate、NACK bitrate）和視頻編碼碼率各占的比率。具體來說，FEC的保護級別（protection level）取決於往返時間RTT，當RTT較小時，丟包重傳的延時不會導致明顯的視頻卡頓，因此可以相應減少FEC包的數量；當RTT較大時，時延對視頻流暢度影響明顯，因此要相應增加FEC包的數量。此外，可以使用多幀FEC和結合時域分層信息的FEC，二者都可以在減小保護開銷的同時，提供更低的渲染抖動、更低的端到端延遲和更高的視頻質量。
二、擁塞控制與自適應帶寬調整
擁塞控制技術的提出由來已久，TCP協議棧默認實現了對網絡的擁塞控制以保證可靠傳輸。但在一些場合TCP並不適用，如：無線傳輸信道，高速長距傳輸網絡、實時通訊應用等。為此，IETF RMCAT（RTP MediaCongestion Avoidance Techniques）工作組提出了一系列針對實時通訊應用的擁塞控制算法需求，包括：能有效控制端到端時延、能有效控制丟包、與其他應用的流共享鏈路帶寬、能夠與TCP長連接流公平競爭可用鏈路帶寬等。Google、Cisco和Ericsson等公司相繼提出了各自的適用於實時交互應用的擁塞控制算法，開源工程WebRTC的內部實現采用Google提出的算法：Google Congestion Control，簡稱GCC。
GCC算法是一種混合了基於丟包和基於時延的方法，原理如下：
-
發送端根據丟包調整目標帶寬，具體來說：低丟包率（小於2%）時增加目標碼率，高丟包率（大於10%）時減小目標碼率，丟包率介於二者之間時目標碼率保持不變；
-
接收端根據時延估計最大帶寬，由三個模塊組成：排隊時延估計、鏈路過載檢測和最大帶寬估計模塊，三個模塊間的關系為：當排隊時延小於閾值（根據網絡狀態自適應調整）時，鏈路檢測結果為underuse；當排隊時延大於閾值時，鏈路檢測結果為overuse；介於二者之間時，鏈路檢測結果為normal；最大帶寬估計模塊的實現是一個表示當前鏈路狀態（Increase、Hold、Decrease）的有限狀態機，初始狀態為Hold，根據鏈路檢測結果進行狀態遷移，並根據遷移后的鏈路狀態和當前接收碼率估計最大帶寬remb。
上述兩個過程的結合之處：接收端計算的remb值通過RTCP REMB反饋到發送端，發送端最終的目標碼率應不超過remb值。
三、關鍵幀請求
關鍵幀也叫做即時刷新幀，簡稱IDR幀。對視頻來說，IDR幀的解碼無需參考之前的幀，因此在丟包C嚴重時可以通過發送關鍵幀請求進行畫面的恢復。關鍵幀的請求方式分為三種：RTCP FIR反饋（Full intra frame request）、RTCP PLI 反饋（Picture Loss Indictor）或SIP Info消息，具體使用哪種可通過協商確定。
四、其他
除上述幾種方法外，還可以通過視頻預處理模塊對視頻內容進行分析，如：運動復雜程度、紋理復雜程度等，與擁塞控制模塊一起進行自適應幀率和自適應分辨率的調整。
綜上所述，在互聯網上為實時交互式音視頻應用提供QoS保證仍是一項挑戰，需要音視頻編碼器、傳輸、預處理等多模塊的協作配合，或利用現有網絡協議和設備的支持，才能提供給客戶更多的選擇和服務保證。