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

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

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

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

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

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

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

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

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

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

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

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

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

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