詳解低延時高音質：丟包、抖動與 last mile 優化那些事兒

本篇是「詳解低延時高音質系列」的第三篇技術分享。我們這次要將視角放大，從整個音訊引擎鏈路的角度，來講講在時變的網路下，針對不同的應用場景，如何權衡音質和互動的實時性。

當我們在討論實時互動場景下的低延時、高音質的時候，我們其實要面對的是從端到端整個音訊引擎鏈路上的音質問題。我們在第一篇文章中，簡單的描繪過一條音訊傳輸的過程，如果在該基礎上再進一步細化，音訊引擎的整個鏈路包含以下各步驟：

1.採集裝置對聲學訊號進行取樣，形成計算機可操作的離散音訊訊號；

2.由於音訊訊號的短時相關性，將音訊訊號進行分幀處理，經過 3A 解決方案處理聲學、環境噪音、回聲、自動增益等問題；

3.編碼器對音訊訊號進行實時壓縮，形成音訊碼流；

4.根據 IP+UDP+RTP+Audio Payload 的格式組包後傳送端將音訊資料包發向網路，重組經過網路到達接收端的資料包；

5.經過抗抖快取和解碼器重建連續的音訊流，播放裝置將連續的音訊流播放出來。

在以上不同的音訊處理環節中，都會不可避免地對音訊訊號產生一些損傷。我們將上述因採集、播放而對音訊訊號引入的損傷稱為「裝置損傷」，在環節 2 引入的損傷稱為「訊號處理損傷」，在編碼與解碼過程中引入的稱為「編碼損傷」，環節 4 中的稱為「網路損傷」。

如果要為使用者提供全頻帶的高質量音訊互動體驗，就需要在上述的音訊引擎鏈路支援全頻帶的處理，並在一些約束條件下（比如來自裝置、網路頻寬、聲學環境等），將各個環節引入的損傷儘可能降低到最小。

當音訊資料進入網路，它會遇到……

如果將網路視作資訊的公路，那麼音訊資料包就像是一輛輛跑在公路上的車。這輛車從北京開到上海，途徑的高速公路就是主幹網路，崎嶇山路就是弱網環境。假設每分鐘都有一輛車從北京出發上路，那麼他們會遇到三個實時傳輸中的常見問題：丟包、延時、抖動。

丟包

“丟包”指的是有的車無法在有效時間內無法達到終點，甚至可能永遠也到不了終點。有的車可能永遠堵在北京的三環上了，有的車可能中途出了車禍。假如我們的一百輛車裡有五輛車因為各種原因沒能按時到達上海，我們這次車隊傳輸的“丟包率”就是 5%。是的，網際網路傳輸也一樣，它並不是百分百可靠的，總有資料無法按時傳輸到目的地。

延時

“延時”指的是每輛車從北京鳥巢開到上海的平均時間。顯然，車隊走高速公路肯定要比走各種小公路快很多，而且從鳥巢出發沿著怎樣的路線開上高速公路也有很大影響，萬一堵在了三環可就要多花好幾個小時了。所以這個值和車隊選擇的行駛路線有關。網際網路傳輸也是一樣的道理，需要傳輸資料的兩點之間經常是有很多可選路徑的，而這些路徑的延時往往相差很大。

抖動

“抖動”指的是車子到達的順序、間隔和出發時的差異。雖然我們的一百輛車在北京是等間隔的一分鐘一輛出發的，但是它們到達上海時卻並不是按順序一分鐘一輛到達的，甚至可能有晚出發的車比早出發的車先到的情況。網際網路傳輸也一樣，如果簡單地按照收到的音視訊資料順序直接播放出來，就會出現失真的現象。

總結來講：

1.在網路上進行實時的音訊互動，編碼後的音訊碼流根據實時傳輸協議組裝成資料包。其中資料包從傳送端按照各自的路線經過網路前往接收端。

2.全球範圍內，不同區域或者不同時間段，使用者網路連線的服務質量有時非常差，且不可靠。

基於上述原因，資料包往往不是按準確的順序到達接收端，而是在錯誤的時間以錯誤的順序到達接收端，或資料包丟失等，這就會出現實時傳輸領域通常提到的問題：網路抖動（jitter），丟包（packet loss），延時（latency）。

丟包、延時、抖動，是基於網際網路進行實時傳輸不可避免的三個問題，不論是在區域網、單一國家地區內傳輸，還是是跨國、跨地區傳輸，都會遇到。

這些網路問題，在不同區域的分佈不同，以聲網Agora 監控的網路實況來看，在網路相對較好的中國地區，99% 的音訊互動需要處理丟包、抖動和網路延時等。這些音訊會話中，20%由於網路問題會有超過 3% 的丟包，10%的會話有超過 8%的丟包。而在印度的表現差異較大，80%的音訊互動中，大約有 40% 的會話丟失。在印度地區優化 2G/3G 網路下的服務質量，仍是提供音訊服務的重點。

抖動、延遲、頻寬的限制也是很多的，這些網路問題導致音訊質量急劇下降，更甚者，影響音訊訊號的可懂度，即不能滿足交換資訊量的本質通訊需求。因此，不論對於使用 WebRTC 的自研團隊，還是提供實時服務的 SDK 服務，嘗試修復這個過程中對音訊訊號引入的損傷，都是必修的課題。

丟包控制

為保證可靠的實時互動，處理丟包是必須的。如果沒有提供連續的音訊資料，使用者會聽到卡頓（glitches、gaps），降低了通話質量和使用者體驗。

丟包問題可以抽象為，如何在不可靠傳輸的網路上，完成可靠傳輸。通常使用前向糾錯 FEC（Forward Error Correction）和自動重傳請求 ARQ（Automatic Repeat-reQuest）兩個糾錯演算法，根據準確的通道狀態估計制定相應策略來解決丟包問題。

FEC 是傳送端通過通道編碼和傳送冗餘資訊，接收端檢測丟包，且在不需要重傳的前提下根據冗餘資訊恢復丟失的大部分資料包。即以更高的通道頻寬作為恢復丟包的開銷。相比ARQ的丟包恢復，FEC 體驗上的延時更小，但由於傳送了冗餘的資料包，所以通道頻寬消耗較多。

ARQ 使用確認資訊 ack（acknowledgements signal，即接收端發回的確認資訊表徵已正確接收資料包）和 timeouts，即如果傳送方在超時前沒有收到確認資訊 ack，則通過滑動視窗協議幫助傳送端決策是否重傳資料包，直到傳送方收到確認資訊 ack 或直到超過預先定義的重傳次數。相比 FEC 的丟包恢復，ARQ 延時較大（因為要等待 ack 或不斷重傳），頻寬利用率不高。

簡單講，丟包控制中使用的 FEC、ARQ 方法是通過額外的通道頻寬，以及延時對丟失的資料包進行恢復。這就是傳統抗丟包方法的現狀，那麼有什麼可行的方法能解決呢？

我們就以之前開源的 Agora SOLO 為例。通常，編解碼器做的事情是壓縮、去冗餘，而抗丟包從一定程度上講是通道處理的擴大化。抗丟包是一種糾錯演算法的擴充套件，通過加冗餘實現抗丟包。而 Agora SOLO 的策略，是把去冗餘和加冗餘進行結合，對重點資訊加冗餘，對非重點資訊則更多的去冗餘，以達到在通道和信源的聯合編碼的效果。

延時、抖動控制

資料包在網路傳輸、排隊時本身就會產生延遲、抖動。同時，我們通過丟包控制恢復的資料包也會引入延時和抖動，通常使用自適應的 de-jitter buffer 機制進行對抗，確保音訊等媒體流連續播放。

正如我們上文比喻的，資料包延遲的變化，我們稱之為抖動（jitter），是一條音訊流或其他媒體流資料包之間端到端單向延時的差異。自適應的邏輯是基於資料包到達間隔（IAT，inter-arrival times）的延時估計進行決策。當出現丟包控制未恢復的資料包、過度的抖動、延時、突發丟包，即超出自適應快取可對抗的延時時，就會出現卡頓。此時接收端一般使用 PLC（Packet Loss Concealment）模組預測新的音訊資料，以填充音訊資料缺失（由於丟包、過度的抖動和延時引入的丟包、突發丟包）等產生的不連續的音訊訊號。

綜上所述，處理網路損傷，是在不可靠的通訊通道上面，通過丟包、延時、抖動控制方法確保資料包儘可能的順序輸出，結合 PLC 預測填充音訊資料的缺失。

要儘可能減小網路損傷，需要結合以下五點增強弱網邊界：

1.準確的網路通道狀態的估計，動態的對丟包控制的策略進行調整和應用；

2.以及相配套的 de-jitter buffer，以更快、更準的學習速度適應網路的非穩態（好網路轉差，差網路轉好，突發的梳狀網路）的變化，調整抗抖快取至大於且更接近於穩態時等價延時的大小，才能確保收聽者在該瞬時網路環境下的音質好，延時低，逐漸趨於理論最優；

3.超出弱網可恢復邊界時，通過降低位元速率（也常用來解決通道擁塞），提升通道頻寬中冗餘資料或重傳次數的開銷；

4.並結合 PLC 對輸入訊號的適應能力，確保不同說話者，時變的背景噪聲下儘可能的減小可察覺的噪聲；

5.在較小頻寬下，通過編碼器編碼低位元速率且高質量的語音，結合3在網路服務質量差的情況下，增加弱網對抗的魯棒性。

基於以上在丟包、延時、抖動的對抗策略，我們就可以基於網際網路傳輸，提供更好的音訊實時互動體驗。就像我們之前說的，不同地區、不同時間段、不同網路下，網路的延時、抖動、丟包情況都不同。而聲網Agora SDK 是面向全球提供高質量的音訊互動服務，讓全球各區域的使用者線上上進行實時互動，通過音訊引擎儘可能將線下的聲學體驗帶給使用者。因此我們也做了多次實地的測試，並觀察 SDK 的 MoS 分（ITU-T P.863）和延時資料表現。

以下是我們在上海中環環線，使用相同裝置，在相同運營商網路下，同時測試的Agora RTC SDK與友商產品的 MOS 分和延時資料。從統計來看，聲網Agora SDK提供的實時音訊互動服務，在提供較高音質的同時，延時更低。

圖：MoS 分對比

圖：延時資料對比

可以從 MoS 分對比圖看出，Agora SDK 的 MOS 主要分佈在高分值[4.5, 4.7]區間段，友商主要分佈在[3.4, 3.8]。再說一個資料大家可能會有更直觀的概念。我們使用的微信，儘管與 RTC SDK 不屬於同一型別的產品，但也提供語音通話服務。微信在無弱網環境下測量的最高 MoS 分是 4.19。

使用者體驗的實際音訊質量，可由以下音訊質量地圖中圓點的顏色顯示，綠色表示 MOS 分大於4.0；黃色表示 MOS 分處於[3.0, 4.0]，紅色表示[1, 3.0]。