1、背景

RTC（Real-time Communications），實(shí)時(shí)通信，是一個(gè)正在興起的風(fēng)口行業(yè)，特別是近兩年電商、教育等行業(yè)直播的普及以及各種設(shè)備之間的音視頻通話場(chǎng)景。從技術(shù)角度來說，RTC并不是一個(gè)新興技術(shù)，從智能手機(jī)流行以來，RTC就已經(jīng)出現(xiàn)在一對(duì)一的音視頻通話場(chǎng)景中，最初的技術(shù)方案也比較直觀，當(dāng)設(shè)備通過服務(wù)端建立通話連接后，兩個(gè)設(shè)備以點(diǎn)對(duì)點(diǎn)的方式直接通信，具體實(shí)現(xiàn)方式就是把編碼壓縮過的音視頻數(shù)據(jù)包通過UDP協(xié)議封包后發(fā)送給接收方，接收方收到UDP數(shù)據(jù)包后，就可以進(jìn)行拆包，解碼并播放，這種方式的特點(diǎn)就是簡單粗暴，不需要關(guān)心網(wǎng)絡(luò)情況，后果是有可能出現(xiàn)丟包，特別是網(wǎng)絡(luò)情況發(fā)生變化時(shí)，會(huì)出現(xiàn)聽不到聲音，畫面卡頓等情況，所以整體用戶體驗(yàn)會(huì)比較差。隨著技術(shù)的發(fā)展進(jìn)步，考慮到網(wǎng)絡(luò)情況隨時(shí)可能發(fā)生變化，在原有技術(shù)方案的基礎(chǔ)上，出現(xiàn)了一些比較有名的網(wǎng)絡(luò)擁塞控制算法，它可以根據(jù)網(wǎng)絡(luò)變化情況控制數(shù)據(jù)包發(fā)送速率，從而平緩網(wǎng)絡(luò)抖動(dòng)造成的一些丟包，卡頓等現(xiàn)象。

在RTC領(lǐng)域，最有名的就是Google的WebRTC，它允許網(wǎng)絡(luò)應(yīng)用或者站點(diǎn)，在不借助中間媒介的情況下，建立瀏覽器之間點(diǎn)對(duì)點(diǎn)（Peer-to-Peer）的連接，實(shí)現(xiàn)視頻流和（或）音頻流或者其他任意數(shù)據(jù)的傳輸，支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時(shí)語音對(duì)話或視頻對(duì)話。WebRTC是一個(gè)開源項(xiàng)目，從功能流程上來說，它包含采集、編碼、前后處理、傳輸、解碼、緩沖、渲染等很多環(huán)節(jié)。比如，前后處理環(huán)節(jié) 有美顏、濾鏡、回聲消除、噪聲抑制等，采集有麥克風(fēng)陣列等，傳輸有擁塞控制，NetEQ等，編解碼有 VP8、VP9、H.264、H.265 等等。這里主要是基于學(xué)習(xí)的角度，簡單介紹WebRTC中比較重要的幾個(gè)算法：擁塞控制算法，NetEQ以及音頻3A（噪聲抑制，回聲消除以及自動(dòng)增益）。

2、擁塞控制算法

WebRTC包含三種擁塞控制算法，GCC（Google Congest Control）、BBR和PCC。這里主要想介紹一下GCC。

GCC核心思想就是通過預(yù)測(cè)可用帶寬來控制發(fā)送的速率，并結(jié)合發(fā)送端和接收端兩端各自估測(cè)的帶寬來綜合計(jì)算，其中發(fā)送端的帶寬估測(cè)主要依賴于丟包率(其實(shí)也有延遲)，接收端的帶寬估測(cè)依賴于延遲(的變化)。打個(gè)比方，GCC的角色就像是一個(gè)繁忙的十字路口的交警，當(dāng)前方道路車輛太多時(shí)，他會(huì)阻止后方車輛繼續(xù)行駛，防止交通堵塞，當(dāng)前方道路車輛較少時(shí)，他會(huì)加速放行，讓后方車輛盡快通過。當(dāng)然，GCC實(shí)際控制流程遠(yuǎn)比交警來的復(fù)雜。換句話說，GCC主要是依靠丟包、延遲、抖動(dòng)等網(wǎng)絡(luò)參數(shù)來預(yù)估當(dāng)前的可用帶寬進(jìn)而控制發(fā)送的速率從而避免網(wǎng)絡(luò)擁塞引起的丟包、延遲、抖動(dòng)等現(xiàn)象，是一個(gè)反饋的過程。

由于WebRTC還有NACK、FEC等策略來解決丟包問題，實(shí)際上發(fā)送端的帶寬估測(cè)對(duì)較小程度的丟包來說并不太敏感，反而是接收端的帶寬估測(cè)對(duì)延遲的抖動(dòng)有較大的靈敏度。GCC的接收端通過一系列算法檢測(cè)當(dāng)前網(wǎng)絡(luò)延遲是否有變化，延遲變大的話，在考慮并消除掉數(shù)據(jù)尺寸變化的影響后，可以認(rèn)為是網(wǎng)絡(luò)路由的擁塞，需要降低碼率，否則在延遲變小的情況下，認(rèn)為網(wǎng)絡(luò)空閑，可以提高碼率。所以在延遲抖動(dòng)較大的情況下，即使沒有丟包，GCC也會(huì)進(jìn)行較大程度的帶寬調(diào)整。也就是說，延遲如果穩(wěn)定的話，即使值較大，也并不影響帶寬的估測(cè)，反過來如果平均延遲比較小，但是出現(xiàn)較多較大的抖動(dòng)，則會(huì)迅速將估測(cè)帶寬調(diào)低。

GCC算法主要分成兩個(gè)部分，一個(gè)是基于丟包的擁塞控制，一個(gè)是基于延遲的擁塞控制。在早期的實(shí)現(xiàn)當(dāng)中，這兩個(gè)擁塞控制算法分別是在發(fā)送端和接收端實(shí)現(xiàn)的。

對(duì)發(fā)送端來講,GCC算法主要負(fù)責(zé)兩件事:

• 接收來自接收端的數(shù)據(jù)包信息反饋,包括來自RTCP RR報(bào)文的丟包率和來自RTCP REMB報(bào)文的接收端估計(jì)碼率,綜合本地的碼率配置信息,計(jì)算得到目標(biāo)碼率A。
• 把目標(biāo)碼率A生效于目標(biāo)模塊,包括PacedSender模塊,RTPSender模塊和ViEEncoder模塊等。

對(duì)于接收端來講,GCC算法主要負(fù)責(zé)兩件事:

• 統(tǒng)計(jì)RTP數(shù)據(jù)包的接收信息,包括丟包數(shù)、接收RTP數(shù)據(jù)包的最高序列號(hào)等,構(gòu)造RTCP RR報(bào)文,發(fā)送回發(fā)送端。
• 針對(duì)每一個(gè)到達(dá)的RTP數(shù)據(jù)包,執(zhí)行基于到達(dá)時(shí)間延遲的碼率估計(jì)算法,得到接收端估計(jì)碼率,構(gòu)造RTCP REMB報(bào)文,發(fā)送回發(fā)送端。

由此可見,GCC算法由發(fā)送端和接收端配合共同實(shí)現(xiàn),接收端負(fù)責(zé)碼率反饋數(shù)據(jù)的生成，發(fā)送端綜合兩個(gè)控制算法的結(jié)果得到一個(gè)最終的發(fā)送碼率，并以此碼率發(fā)送數(shù)據(jù)包。

3、NetEQ算法

NetEQ是webRTC中音頻技術(shù)方面的兩大核心技術(shù)之一，另一核心技術(shù)是音頻3A算法（AEC、ANS以及AGC）。在音視頻實(shí)時(shí)通信領(lǐng)域，網(wǎng)絡(luò)環(huán)境是影響音視頻質(zhì)量最關(guān)鍵的因素，當(dāng)網(wǎng)絡(luò)質(zhì)量比較差時(shí)，再好的音視頻算法都顯得有些心有余而力不足。網(wǎng)絡(luò)質(zhì)量差的表現(xiàn)主要有延時(shí)、亂序、丟包、抖動(dòng)，其中丟包和抖動(dòng)是最常見的。抖動(dòng)是數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸忽快忽慢，丟包是數(shù)據(jù)包經(jīng)過網(wǎng)絡(luò)傳輸，因?yàn)楦鞣N原因被丟掉了，所以處理好丟包和抖動(dòng)，是獲得優(yōu)質(zhì)音視頻體驗(yàn)的關(guān)鍵因素。

RTC音頻通訊部分正常的工作流程如下：首先在發(fā)送端采集音頻數(shù)據(jù)，并對(duì)采集到的聲音信號(hào)進(jìn)行回聲消除，噪聲抑制以及自動(dòng)增益控制等前處理，然后進(jìn)行語音壓縮編碼，封裝成RTP包并通過網(wǎng)絡(luò)發(fā)送到接收端，接收端接收到數(shù)據(jù)后，進(jìn)行RTP解包，然后進(jìn)行抖動(dòng)消除，丟包隱藏，解碼等操作，最后將處理過后的音頻數(shù)據(jù)送給播放器播放。其中NetEQ涉及的操作包含抖動(dòng)消除，解碼以及相應(yīng)的音頻信號(hào)處理，簡單來講，NetEQ本質(zhì)上就是一個(gè)音頻的抖動(dòng)緩沖器（JitterBuffer），它工作在音頻數(shù)據(jù)接收端，通過抖動(dòng)消除，丟包隱藏等操作達(dá)到音頻流暢播放的目的。

抖動(dòng)現(xiàn)象是怎么產(chǎn)生的呢？如上圖，在沒有技術(shù)干預(yù)的情況下，發(fā)送端按照20ms的時(shí)間間隔發(fā)送音頻數(shù)據(jù)包，由于網(wǎng)絡(luò)延遲等影響，數(shù)據(jù)包到達(dá)的時(shí)間并不是均勻的，這時(shí)候如果直接送到播放器播放，我們聽聲的聲音是存在抖動(dòng)現(xiàn)象的，為了避免這種情況，我們通常做法是通過抖動(dòng)緩沖技術(shù)來消除，即在接收方建立一個(gè)緩沖區(qū)，語音包達(dá)到接收端時(shí)，首先進(jìn)入緩沖區(qū)暫存，隨后系統(tǒng)再以平滑的速率將語音包從緩沖區(qū)取出，經(jīng)過解碼后播放出來。當(dāng)然，只是簡單的設(shè)一個(gè)緩沖區(qū)是遠(yuǎn)遠(yuǎn)不夠的，因?yàn)榫彌_區(qū)設(shè)的太小，有可能起不到緩沖效果，設(shè)的太大，有可能導(dǎo)致音頻延遲，那緩沖區(qū)到底要設(shè)多大呢？這個(gè)就要看具體情況了。抖動(dòng)消除思想的理想狀態(tài)是每個(gè)數(shù)據(jù)包在網(wǎng)絡(luò)傳輸中的延遲與其在抖動(dòng)緩沖區(qū)中緩沖的延遲之和應(yīng)該相等，因此一般的抖動(dòng)消除思想是將抖動(dòng)緩沖區(qū)大小設(shè)為目前測(cè)到的最大網(wǎng)絡(luò)延遲大小，而且每個(gè)包在網(wǎng)絡(luò)中的延遲加上其在抖動(dòng)緩沖區(qū)中緩沖產(chǎn)生的延遲之和應(yīng)該等于抖動(dòng)緩沖區(qū)大小。

目前抖動(dòng)緩沖控制算法包含靜態(tài)抖動(dòng)緩沖控制算法和自適應(yīng)抖動(dòng)緩沖控制算法，靜態(tài)抖動(dòng)緩沖控制算法指的是緩沖區(qū)大小是固定值，對(duì)于超出緩沖區(qū)大小的數(shù)據(jù)包將會(huì)丟棄。這種算法模型小，實(shí)現(xiàn)起來比較簡單，但在弱網(wǎng)情況下比較容易丟包；自適應(yīng)抖動(dòng)緩沖控制算法的緩沖區(qū)大小是隨著實(shí)際網(wǎng)絡(luò)的抖動(dòng)情況而調(diào)整的，接收端將收到的數(shù)據(jù)包延遲與當(dāng)前保存的延遲信息進(jìn)行比較，得到當(dāng)前網(wǎng)絡(luò)最大抖動(dòng)，從而選擇合適的緩沖區(qū)大小。這種算法的優(yōu)點(diǎn)是網(wǎng)絡(luò)抖動(dòng)較大時(shí)丟包率較低，網(wǎng)絡(luò)延遲小時(shí)，語音延遲相對(duì)也比較小。NetEQ采用的抖動(dòng)消除技術(shù)屬于自適應(yīng)抖動(dòng)緩沖算法。

除了抖動(dòng)緩沖，NetEQ還實(shí)現(xiàn)了丟包隱藏（Packet Loss Concealment）,所謂的丟包隱藏，指的是發(fā)生丟包時(shí)，產(chǎn)生一個(gè)與丟失語音包相似的替代語音。NetEQ中的丟包隱藏技術(shù)和解碼器是密切相關(guān)的，它在解碼端根據(jù)收到的數(shù)據(jù)逐幀解碼過程中，先判斷當(dāng)前幀是否完整，如果是完整的，則按照正常的解碼流程進(jìn)行解碼，如果發(fā)現(xiàn)數(shù)據(jù)丟失，那么進(jìn)入特殊的丟包隱藏模塊進(jìn)行數(shù)據(jù)包補(bǔ)償，這種補(bǔ)償方式比較復(fù)雜，這里就不多做介紹了。

4、音頻3A算法

音頻3A算法指的是在發(fā)送端對(duì)發(fā)送信號(hào)依次進(jìn)行回聲消除、降噪以及音量均衡操作，它包含三個(gè)算法：AEC(回聲消除)，ANS（噪聲抑制）和AGC（自動(dòng)增益控制）。音頻3A是在數(shù)據(jù)發(fā)送端進(jìn)行的，當(dāng)發(fā)送端采集到音頻數(shù)據(jù)后，在編碼之前，會(huì)先進(jìn)行信號(hào)處理，這里的信號(hào)處理主要指的就是音頻3A。不同于擁塞控制算法和NetEQ，音頻3A算法和網(wǎng)絡(luò)無關(guān)，它是純粹的音頻信號(hào)處理算法，目前很多設(shè)備的音頻3A實(shí)際上是通過硬件實(shí)現(xiàn)的。

4.1、AEC（回聲消除）

在正常的音頻通話流程中，我們說話的聲音除了第一次直接被麥克風(fēng)捕捉到，還會(huì)經(jīng)過多次空間反射再次被麥克風(fēng)捕捉并采集到系統(tǒng)中，此時(shí)音頻的輸入既有本人說話的聲音，又有空間反射的回聲，如果不做處理，遠(yuǎn)端聽到的聲音是帶有回音的，還有一種情況是遠(yuǎn)端傳過來的聲音經(jīng)過設(shè)備揚(yáng)聲器播放后，又被設(shè)備的麥克風(fēng)采集到，如果不做處理，對(duì)方能出自己設(shè)備的揚(yáng)聲器中聽到自己剛才講話的聲音，這對(duì)于用戶來說是一種非常差的體驗(yàn)。

在真實(shí)的語音場(chǎng)景中，麥克風(fēng)采集到的聲音是一個(gè)混合體，它包含近端以及遠(yuǎn)端的聲音，簡單來講，AEC期望的是從混合的近端信號(hào)中消除不需要的遠(yuǎn)端信號(hào)，保留近端人聲發(fā)送到遠(yuǎn)端。因此，回聲消除的關(guān)鍵就是如何區(qū)分近端和遠(yuǎn)端的聲音，如果我們能夠產(chǎn)生一種信號(hào)，中和掉遠(yuǎn)端的聲音，那么自然就能消除掉回聲。那具體該如何做呢？我們以遠(yuǎn)端傳過來的聲音經(jīng)過設(shè)備揚(yáng)聲器播放后，又被設(shè)備麥克風(fēng)采集到并發(fā)送回去產(chǎn)生的回聲為例，簡單來講分三步：

• 首先找出揚(yáng)聲器信號(hào)跟麥克風(fēng)信號(hào)之間的延遲；
• 其次根據(jù)揚(yáng)聲器信號(hào)估計(jì)出麥克風(fēng)信號(hào)中的線性回聲成分，并將其從麥克風(fēng)信號(hào)中減去，得到殘差信號(hào)。

• 最后通過非線性的處理將殘差信號(hào)中的殘余回聲給徹底抑制掉。

所以回聲消除也由三個(gè)大的算法模塊組成：延遲估計(jì)（Delay Estimation），線性自適應(yīng)濾波器（Linear Adaptive Filter）以及非線性處理（Nonlinear Processing）。

其中延遲估計(jì)決定了AEC的下限，線性自適應(yīng)濾波器決定了 AEC 的上限，非線性處理決定了最終的通話體驗(yàn)。

4.2、ANS（噪聲抑制）

所謂噪聲抑制就是我們平常所說的降噪，我們常用的降噪耳機(jī)就是基于此打造的。噪聲分為平衡噪聲和瞬時(shí)噪聲兩類，平穩(wěn)噪聲的頻譜穩(wěn)定，瞬時(shí)噪聲的頻譜能量方差小，利用噪聲的特點(diǎn)，對(duì)音頻數(shù)據(jù)添加反向波形處理，即可消除噪聲。噪聲跟語音信號(hào)不同，降噪過程中其實(shí)是通過在頻域做一些處理。對(duì)于一些平穩(wěn)的噪聲，比如常見的空調(diào)聲、電腦風(fēng)扇聲、車內(nèi)的一些風(fēng)噪聲，它的時(shí)間變化比較慢，但是語音是一個(gè)多變的信號(hào)，正是通過它們兩個(gè)的不同，我們來判斷哪些信號(hào)是語音，哪些是降噪，然后把它給去掉。關(guān)于噪聲抑制的介紹，相關(guān)的資料也不少，具體就不詳細(xì)介紹了。

4.3、AGC（自動(dòng)增益控制）

AGC單純從名詞解釋上比較不好理解，什么是自動(dòng)增益控制？我們可以先以現(xiàn)實(shí)場(chǎng)景中的音視頻會(huì)議為例，在真實(shí)場(chǎng)景中，不同參會(huì)人由于距離遠(yuǎn)近以及每個(gè)人說話音量不同，當(dāng)設(shè)備通過麥克風(fēng)采集到音頻數(shù)據(jù)后，如果不做處理，那么遠(yuǎn)端聽到的音量大小會(huì)有很大的差異，所以對(duì)發(fā)送端音量的均衡在上述場(chǎng)景中顯得尤為重要，自動(dòng)增益控制算法的目標(biāo)是能夠統(tǒng)一音頻音量大小，緩解由設(shè)備采集差異、說話人音量大小、距離遠(yuǎn)近等因素導(dǎo)致的音量的差異。

在3A音頻處理算法中，AGC位于最后的位置，它主要在發(fā)送端作為均衡器和壓限器調(diào)整推流音量，針對(duì)不同的接入設(shè)備 WebRTC AGC 提供了三種模式：固定數(shù)字增益（FixedDigital），自適應(yīng)模擬增益（AdaptiveAnalog）以及自適應(yīng)數(shù)字增益 （AdaptiveDigital）， 其中固定數(shù)字增益模式最基礎(chǔ)的增益模式也是 AGC 的核心，其他兩種模式都是在此基礎(chǔ)上擴(kuò)展得到。固定數(shù)字增益主要是對(duì)信號(hào)進(jìn)行固定增益的放大，最大增益不超過設(shè)置的增益能力，自適應(yīng)模擬增益，顧名思義，就是能夠增對(duì)模擬增益進(jìn)行動(dòng)態(tài)調(diào)整，它主要工作在PC端，自適應(yīng)數(shù)字增益為了滿足智能手機(jī)和平板設(shè)備，這些移動(dòng)端并沒有類似 PC 端調(diào)節(jié)模擬增益的接口，它的工作原理類似于自適應(yīng)模擬增益。

5、小結(jié)

RTC領(lǐng)域積累了很多音視頻以及流媒體相關(guān)的高質(zhì)量算法，我們介紹的擁塞控制，NetEQ以及音頻3A算法是其中比較重要的，業(yè)界也有很多深入的講解，本文主要基于學(xué)習(xí)和科普的角度做一些簡單介紹，更詳細(xì)的內(nèi)容大家可以參考相關(guān)文章以及WebRTC代碼實(shí)現(xiàn)。

參考文章

1. WebRTC的擁塞控制技術(shù)
2. webRTC中音頻相關(guān)的netEQ
3. webrtc語音引擎中neteq技術(shù)的研究
4. 詳解 WebRTC 高音質(zhì)低延時(shí)的背后 — AGC

開發(fā)者支持

如需更多技術(shù)支持，可加入釘釘開發(fā)者群，或者關(guān)注微信公眾號(hào)。

更多技術(shù)與解決方案介紹，請(qǐng)?jiān)L問HaaS官方網(wǎng)站https://haas.iot.aliyun.com