1、背景

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

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

2、擁塞控制算法

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

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

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

GCC算法主要分成兩個部分，一個是基于丟包的擁塞控制，一個是基于延遲的擁塞控制。在早期的實現當中，這兩個擁塞控制算法分別是在發送端和接收端實現的。

對發送端來講,GCC算法主要負責兩件事:

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

對于接收端來講,GCC算法主要負責兩件事:

• 統計RTP數據包的接收信息,包括丟包數、接收RTP數據包的最高序列號等,構造RTCP RR報文,發送回發送端。
• 針對每一個到達的RTP數據包,執行基于到達時間延遲的碼率估計算法,得到接收端估計碼率,構造RTCP REMB報文,發送回發送端。

由此可見,GCC算法由發送端和接收端配合共同實現,接收端負責碼率反饋數據的生成，發送端綜合兩個控制算法的結果得到一個最終的發送碼率，并以此碼率發送數據包。

3、NetEQ算法

NetEQ是webRTC中音頻技術方面的兩大核心技術之一，另一核心技術是音頻3A算法（AEC、ANS以及AGC）。在音視頻實時通信領域，網絡環境是影響音視頻質量最關鍵的因素，當網絡質量比較差時，再好的音視頻算法都顯得有些心有余而力不足。網絡質量差的表現主要有延時、亂序、丟包、抖動，其中丟包和抖動是最常見的。抖動是數據在網絡上的傳輸忽快忽慢，丟包是數據包經過網絡傳輸，因為各種原因被丟掉了，所以處理好丟包和抖動，是獲得優質音視頻體驗的關鍵因素。

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

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

目前抖動緩沖控制算法包含靜態抖動緩沖控制算法和自適應抖動緩沖控制算法，靜態抖動緩沖控制算法指的是緩沖區大小是固定值，對于超出緩沖區大小的數據包將會丟棄。這種算法模型小，實現起來比較簡單，但在弱網情況下比較容易丟包；自適應抖動緩沖控制算法的緩沖區大小是隨著實際網絡的抖動情況而調整的，接收端將收到的數據包延遲與當前保存的延遲信息進行比較，得到當前網絡最大抖動，從而選擇合適的緩沖區大小。這種算法的優點是網絡抖動較大時丟包率較低，網絡延遲小時，語音延遲相對也比較小。NetEQ采用的抖動消除技術屬于自適應抖動緩沖算法。

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

4、音頻3A算法

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

4.1、AEC（回聲消除）

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

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

• 首先找出揚聲器信號跟麥克風信號之間的延遲；
• 其次根據揚聲器信號估計出麥克風信號中的線性回聲成分，并將其從麥克風信號中減去，得到殘差信號。

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

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

其中延遲估計決定了AEC的下限，線性自適應濾波器決定了 AEC 的上限，非線性處理決定了最終的通話體驗。

4.2、ANS（噪聲抑制）

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

4.3、AGC（自動增益控制）

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

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

5、小結

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

參考文章

1. WebRTC的擁塞控制技術
2. webRTC中音頻相關的netEQ
3. webrtc語音引擎中neteq技術的研究
4. 詳解 WebRTC 高音質低延時的背后 — AGC

開發者支持

如需更多技術支持，可加入釘釘開發者群，或者關注微信公眾號。

更多技術與解決方案介紹，請訪問HaaS官方網站https://haas.iot.aliyun.com