本篇是「詳解低延時高音質系列」的第三篇技術分享。我們這次要將視角放大,從整個音訊引擎鏈路的角度,來講講在時變的網路下,針對不同的應用場景,如何權衡音質和互動的實時性。
當我們在討論實時互動場景下的低延時、高音質的時候,我們其實要面對的是從端到端整個音訊引擎鏈路上的音質問題。我們在第一篇文章中,簡單的描繪過一條音訊傳輸的過程,如果在該基礎上再進一步細化,音訊引擎的整個鏈路包含以下各步驟:
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]。
圖:上海中環,Agora SDK 的音訊質量
圖:上海中環,友商 的音訊質量
小結
丟包、延時、抖動是在實時互動場景下不可避免的問題。而且這些問題不僅會由於網路環境、時段、使用者裝置等因素不斷產生變化,也會由於底層技術的發展而產生新的變化(比如 5G 的大規模應用)。所以我們針對它們的優化策略也要不斷迭代優化。
在跟隨音訊訊號從傳送端經過網路到達接收端之後,音訊體驗的優化並沒有結束。為了“高音質體驗”,我們還要進一步在端上優化音質,下一篇我們詳細分享其冰山一角,敬請期待。
相關閱讀