隨著WebRTC標準的逐步推廣，實時音視頻通訊技術(shù)受到越來越多公司和技術(shù)人員的關(guān)注。對于交互式音視頻應用而言，穩(wěn)定、低延時、通話質(zhì)量清晰可靠是其基本需求。在互聯(lián)網(wǎng)環(huán)境下，音視頻的通話質(zhì)量與以下因素有關(guān)：一是編碼碼率、幀率和分辨率等編碼因素；二是網(wǎng)絡(luò)的接入類型和接入設(shè)備性能；三是對丟包、抖動、亂序以及網(wǎng)絡(luò)擁塞的自適應調(diào)整能力，即QoS（Qualityof Service，服務質(zhì)量）。容聯(lián)云通訊是國內(nèi)最早且通訊能力最全的PaaS服務商，在推出音視頻通話這一關(guān)鍵能力時，更加注重保證QoS（Qualityof Service，服務質(zhì)量），提升用戶體驗。本文主要介紹為保證QoS，在音視頻傳輸和處理過程中采用的關(guān)鍵技術(shù)。

　　交互式實時視頻應用通常采用RTP協(xié)議進行音視頻傳輸，RTP頭部提供了諸如負載類型、時間戳、序列號和同步源等信息保證基本的音視頻傳輸需求。但與TCP不同，RTP協(xié)議底層采用不可靠的UDP傳輸層協(xié)議，當網(wǎng)絡(luò)過載或擁塞，無法實現(xiàn)對丟包、抖動、亂序以及網(wǎng)絡(luò)擁塞的自適應調(diào)整。與音頻相比，視頻傳輸由于所占的帶寬更大，更易受到網(wǎng)絡(luò)環(huán)境變化的影響，因此以下將以視頻為例分析Qos提升途徑。

　　對與實時視頻來說，網(wǎng)絡(luò)出現(xiàn)丟包將直接導致接收端畫面出現(xiàn)馬賽克和花屏。有多種策略可以解決，包括：基于NACK反饋的丟包重傳，前向糾錯FEC和參考幀選擇RPS，這些策略通常與編解碼端的容錯技術(shù)（如：幀內(nèi)刷新和錯誤隱藏）配合使用。

　　基于NACK反饋的丟包重傳方法：接收端循環(huán)檢查接收緩沖，當發(fā)現(xiàn)丟包后使用RTCPNACK反饋報文將丟包信息反饋給發(fā)送端；發(fā)送端接收NACK反饋并解析后從發(fā)送緩存取出對應RTP包，并再次發(fā)送給接收端。該方法的缺點是增大了端到端的延遲，尤其在丟包大量發(fā)生時更為明顯。

　　前向糾錯FEC：FEC機制是在接收端根據(jù)視頻幀的重要性（參考幀或非參考幀）發(fā)送冗余的視頻RTP包，在接收端如果檢測到丟包則利用冗余包進行恢復，否則將冗余包丟棄。該方法的優(yōu)點是視頻無延遲，但發(fā)送冗余包占用了額外的帶寬資源。

　　更為可行的方案是是混合NACK／FEC模式，接收端根據(jù)幀大小和接收時延估計可用帶寬，發(fā)送端根據(jù)可用帶寬、丟包和RTT等反饋計算分配保護開銷（protectionoverhead，包括FEC bitrate、NACK bitrate）和視頻編碼碼率各占的比率。具體來說，F(xiàn)EC的保護級別（protectionlevel）取決于往返時間RTT，當RTT較小時，丟包重傳的延時不會導致明顯的視頻卡頓，因此可以相應減少FEC包的數(shù)量；當RTT較大時，時延對視頻流暢度影響明顯，因此要相應增加FEC包的數(shù)量。此外，可以使用多幀F(xiàn)EC和結(jié)合時域分層信息的FEC，二者都可以在減小保護開銷的同時，提供更低的渲染抖動、更低的端到端延遲和更高的視頻質(zhì)量。

　　擁塞控制技術(shù)的提出由來已久，TCP協(xié)議棧默認實現(xiàn)了對網(wǎng)絡(luò)的擁塞控制以保證可靠傳輸。但在一些場合TCP并不適用，如：無線傳輸信道，高速長距傳輸網(wǎng)絡(luò)、實時通訊應用等。為此，IETFRMCAT（RTP Media Congestion Avoidance Techniques）工作組提出了一系列針對實時通訊應用的擁塞控制算法需求，包括：能有效控制端到端時延、能有效控制丟包、與其他應用的流共享鏈路帶寬、能夠與TCP長連接流公平競爭可用鏈路帶寬等。Google、Cisco和Ericsson等公司相繼提出了各自的適用于實時交互應用的擁塞控制算法，開源工程WebRTC的內(nèi)部實現(xiàn)采用Google提出的算法：Google Congestion Control，簡稱GCC。

　　GCC算法是一種混合了基于丟包和基于時延的方法，原理如下：

　　發(fā)送端根據(jù)丟包調(diào)整目標帶寬，具體來說：低丟包率（小于2%）時增加目標碼率，高丟包率（大于10%）時減小目標碼率，丟包率介于二者之間時目標碼率保持不變；

　　接收端根據(jù)時延估計最大帶寬，由三個模塊組成：排隊時延估計、鏈路過載檢測和最大帶寬估計模塊，三個模塊間的關(guān)系為：當排隊時延小于閾值（根據(jù)網(wǎng)絡(luò)狀態(tài)自適應調(diào)整）時，鏈路檢測結(jié)果為underuse；當排隊時延大于閾值時，鏈路檢測結(jié)果為overuse；介于二者之間時，鏈路檢測結(jié)果為normal；最大帶寬估計模塊的實現(xiàn)是一個表示當前鏈路狀態(tài)（Increase、Hold、Decrease）的有限狀態(tài)機，初始狀態(tài)為Hold，根據(jù)鏈路檢測結(jié)果進行狀態(tài)遷移，并根據(jù)遷移后的鏈路狀態(tài)和當前接收碼率估計最大帶寬remb。

　　上述兩個過程的結(jié)合之處：接收端計算的remb值通過RTC PREMB反饋到發(fā)送端，發(fā)送端最終的目標碼率應不超過remb值。

　　關(guān)鍵幀也叫做即時刷新幀，簡稱IDR幀。對視頻來說，IDR幀的解碼無需參考之前的幀，因此在丟包C嚴重時可以通過發(fā)送關(guān)鍵幀請求進行畫面的恢復。關(guān)鍵幀的請求方式分為三種：RTCPFIR反饋（Full intra frame request）、RTCPPLI反饋（Picture Loss Indictor）或SIPInfo消息，具體使用哪種可通過協(xié)商確定。

　　除上述幾種方法外，還可以通過視頻預處理模塊對視頻內(nèi)容進行分析，如：運動復雜程度、紋理復雜程度等，與擁塞控制模塊一起進行自適應幀率和自適應分辨率的調(diào)整。

　　綜上所述，在互聯(lián)網(wǎng)上為實時交互式音視頻應用提供QoS保證仍是一項挑戰(zhàn)，需要音視頻編碼器、傳輸、預處理等多模塊的協(xié)作配合，或利用現(xiàn)有網(wǎng)絡(luò)協(xié)議和設(shè)備的支持，才能提供給客戶更多的選擇和服務保證。