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