IP通訊中音頻編解碼技術與抗丟包技術概要

此文較長，建議收藏起來看。

1、一個典型的IP通訊模型

2、Server2Server技術分類

Server2Server這塊也是一個專門的領域，這裏只簡單分個類。

一、同一國家相同運營商之間：

同一運營商之間也有丟包，在鐵通，鵬博士等運營商中尤甚。而且在晚高峯的時候表現更加突出。

二、同一國家不一樣運營商之間：

在不少時候，因爲運營商之間的結算和有限帶寬的問題。運營商之間的網絡不穩定。

三、不一樣國家之間：

同一個國家都這麼多問題，不一樣國家的問題回更復雜，在不一樣的國家要選擇好的機房，實時選擇實時監控。好比如下地方。如下地區，咱們端到端延時平均爲157ms。

• 中美，中歐

• 東亞：中，日本，韓國，臺灣

• 其餘地區：拉丁美洲，印度，菲律賓，泰國，南非，中東

3、Server2Device——Lastmile技術簡介

咱們在公網作實時音視頻服務，丟包對抗是少不了的。

首先咱們定義下什麼是丟包：沒按時到的包就是丟包。一個包應該在某個時間點到，但它晚到了，即便來了可是晚了，也叫丟包。由於播放的這段時間已通過去了，即便放了，體驗也很差。從整個網絡上看，丟包必定有時限，不然，都經過反覆重傳方法，必定能送達一個包。

Server到達device這塊還能夠分如下兩種通路。

一、Server通過基站到Device

能夠分爲如下幾種狀況：

• 不一樣類型的基站：3G/4G,TD和WDCDMA就不同。

• 相同類型的基站不一樣的地點：北京聯通推出流量包月下行最高150kbps的服務

• 相同基站相同地點不一樣時間：球賽，運動會，熱點彙集區附近的基站

• 不一樣國家的基站:中國的WCDMA和印度的WCDMA和美國的WCDMA

二、Server通過家用路由器到Device

2.4G路由和5G路由，2.4G路由覆蓋面積廣，可是2.4G頻段很髒，容易干擾和丟包。5G路由相對好些，可是覆蓋面積小。而且在公司內部，會有多個路由，不少人連一個路由。競爭嚴重，有時網絡丟包會很高。而且有些路由器是有bug的，好比小米路由的梳狀抖動模型。

4、Device技術簡介

AVDM，AVPM，AVCM，AVNM

一、AVDM(Audio Video Device Module)：

AVDM是主要針對device的播放，錄音錄像端作處理的模塊。不一樣的平臺會有不一樣的驅動和錄音錄像需求，好比XP、Vista、win七、win8。咱們不能一律而論的統一選擇dshow甚至是waveout來播放仍是錄音。在移動端、iOS、安卓，安卓自己也有java和opensles兩種錄音方法，而且還有一系列的配置參數。好比用什麼樣的參數能錄立體聲，關閉手機自帶處理，錄高音質聲音，延時低等等。和device相關的還有就是硬件能力：GPU、CPU的能力，對於視頻而言，不一樣的CPU能支持怎麼樣的視頻編解碼能力輸出。

二、AVPM(Audio Video Processing Module)

AVPM在視頻上指美顏、降噪。音頻的通常先後後處理包括3A引擎、AEC、ANS、AGC、混音、加混響（音樂直播）、去混響（會議模式）。是否應該用GPU，什麼狀況下應該用GPU。用GPU是爲了省電仍是運算快？

三、AVCM(Audio Video Coding Module)

編解碼器的選擇和處理，視頻包括是選擇VP八、VP9，仍是選擇26四、265，是用硬件仍是用軟件，是否涉及專利問題。選擇硬件會遇到什麼問題，選擇軟件會遇到什麼問題，爲何用硬件會遇到不少參數不能配置的問題。是否須要和硬件廠商配合。安卓碎片化致使的硬件支持問題。高通的硬件支持有什麼問題，mtk的硬件支持有什麼特色。硬件支持是否還要交專利費。

四、AVNM

音視頻的JitterBuffer，FEC，PLC，BWE。
Jitterbuffer主要是爲了對抗網絡抖動，對不熟悉Jitterbuffer的人，早期咱們經會聽到一種理解，jitter爲何不拉大啊？另外jitterbuffer的設計也是要結合更多的輸入才能更好發揮做用。

BWE：帶寬估計，用於估計網絡的帶寬，以便實時調整。可是這裏會有兩種估計模型，基於RTT和基於丟包，如何選擇？

以上每一個點都能講或者寫不少內容，本文只作簡單梳理、點到爲止，之後再作專題分析。

5、IP通訊的幾種結構

1. 1v1的雙工通訊結構（交互）：最簡單的一對一通訊，要作好也不容易。

2. MxM的全雙工通訊結構（交互）: 小型會議。（這塊要注意，在移動設備上首先要移動設備的尺寸問題，展現方法和技術要求也有不一樣，好比多人會議時會有多種layout可能，一大N小，平均分屏）。

3. 1xN的單工通訊結構（直播）

4. MxMxN的單雙工混合結構（交互直播）

5. N的短延時方案，隨時交互

6. N的長延時方案，永不交互（9158實際在比較早的時候就實現了這種技術）。

6、音頻編解碼器選擇與丟包對抗方法介紹

前面概述了基本網絡模型和一些技術需求點，下面我針對本次重點作個分享：編解碼器的選擇和抗丟包技術。這兩項技術對整個通訊網絡都有影響，在不一樣的網絡條件下選擇方法也不一樣。但通常來講，正確的選擇編解碼器和對應的抗丟包技術對Lastmile和端到端的音頻質量影響最大。VOIP通訊很早就有了，在不一樣的時代，咱們選擇了不一樣的編解碼器實現對音頻的傳輸，咱們一般會作下面的分類。

一、VOIP通訊中Codec選擇的幾個時代。

1）ITU Gxxx時代：G711，G722，G723.1，G729ab等等

G711主要用在移動通訊基站和基站之間的包交換網絡中，而且在有些提供VOIP服務的監控攝像頭上使用。64kbps，8khz壓縮。

G722系列包括G722,G722.1,G722.2。是針對WB，16khz和SWB 32khz的壓縮算法。比較著名的是G722.1 也就是Polycom的Siren Codec，他的特色語音編解碼爲數很少的頻域編碼框架，不只對語音支持比較好，對音樂支持也還能夠。在Polycom的VOIP設備中一般支持該編解碼器。

G722.2就是AMR-WB+，是32khz語音編解碼器，同時支持音樂編碼，是AMR-WB的超寬帶版本，可是因爲他前向兼容AMR系列的框架，內核選擇了CELP編解內核，對音樂編碼有先天的問題

2）AMRNB/WB，Speex，ILBC/ISAC，SILK時代

AMR系列：做爲8kbps~12kbps的語音編解碼器，在一段時間內，質量是不錯的，畢竟他是WCDMA和TDCDMA標準選擇的語音編解碼器。也經過3GPP標準開源。在有一段時間Yy語音和QTalk，微信語音留言都使用了AMR編解碼器。可是他的問題是，有專利費，固定比特率。抗丟包性能通常。

• Speex：Speex是由Jean Marc Valin（也是CELT的主要發明人）開發的編解碼器，特色是免專利費，開源。支持寬帶超寬帶。缺點是這個編解碼器多是爲了避開專利，而且受限於不少因素，編碼質量並很差。不管是窄帶寬帶超寬帶，對抗丟包，質量都很通常。可是這也是站在今天的角度看當時的技術，而且在當時可以提供免專利費的全頻帶，低速率（16kbps左右）語音編解碼器確實沒有，能夠說，Speex填補了空白。而且Speex有一個顯著特色是，Speex實際上不是一個編解碼器，是一個音頻處理集。包括AGC，AEC，ANS。能夠完整的應用在一個VOIP通訊系統中，而且他的AEC的自適應濾波部分作的至關不錯，在PC上能夠拿來使用。

• ILBC和ISAC：ILBC編解碼器是GIPS（WebRTC前身）第一個開源出來的編解碼器。8khz，13.3kbps。窄帶編解碼器。他的特色是，抗丟包性好。信源編碼的基礎是去冗餘，信道編碼的基礎是加冗餘。去冗餘的弊端就是抗丟包差，因此ILBC反其道行之，減小幀間冗餘的壓縮，增長每一個幀獨立性，使得當發生丟包的時候，丟包對抗效果好。ILBC在部分呼叫中心公司有普遍應用。ISAC是在GIPS被收購以後伴隨WebRTC開源的編解碼器，他的特色是支持16khz，24khz，32khz。支持帶寬估計（這是不少語音編解碼器不具有的）。而且他不是基於CELP框架，使用了頻域編碼框架+格型編碼+算數編碼的框架。具備必定特殊性。ISAC繼承了ILBC的抗丟包優勢，可是缺點也至關突出，因爲用了頻域編碼器，高頻語音編碼效果很差，聽起來有金屬音，PESQ-WB MOS分低。

• SILK：SILK面世時代比較晚，是以上編解碼器中最晚開發一個編解碼器。他的發明人是Ken Vos，也是ILBC，ISAC的主要開發者。Ken VOS在離開GIPS以後去了高通，爲高通開發了一個寬帶編解碼器。而後到Skype爲Skype開發SILK。Skpye有一段時間也是使用GIPS的方案，用ILBC和ISAC。後面本身開發Codec，他們第一個本身的Codec是VSOPC(好像，這裏缺一個wiki的連接)。可是質量不好，用戶抱怨。故請來了Vos開發SILK。Vos又在Skpye嘗試新框架，Vos的SILK使用了預測加噪聲整形的混合框架（第一使用相似框架的是Broadcom的BV16，BV32編解碼器）。使用STP+LTP+STNS+LTNS兩層後反饋嵌套（BV16和BV32是一個前饋+一個後饋，這裏差圖和wiki連接）。而且引入Delay Decision量化搜索方法，使得標量量化具備矢量量化的性能指標。能夠說SILK的質量是很是好的一個編解碼器。（這裏差一個表），不管主觀仍是客觀。雖然他充分挖掘相關性，但因爲作到極致和很是完美，使得在丟包對抗上有必定幫助。而且他開發了RED輔助編碼算法，提升他的抗丟包能力。

我我的，是很是推薦初級和中級算法工程師仔細閱讀SILK編解碼器，代碼質量好（EE工程師中少見），而且用了不少基礎算法，不少小技巧，甚至包括自動控制理論。對提高本身的能力頗有幫助。

3）Opus/EVS時代

Opus在2012年橫空出世，按照官網的說法，opus比HEAAC好，並給了一些demo。但事實真的是這樣嗎，Opus是由SILK+CELT混合的編碼器，學術上的叫法叫作USAC，Unify Speech and Audio Coding。這點，EVS也是。意思是不區分音樂語音的編解碼器。這個編解碼器內有個一Music detector去判斷當前幀是語音仍是音樂，語音選擇語言框架編碼，音樂選擇音樂框架編碼（注意目前尚未統一框架，緣由是框架通常是人體生理模擬，由於人有兩個聲學器官，嘴和耳朵，因此語音是針對聲帶，口腔，鼻腔見面，音樂是根據人耳朵結構的時間掩蔽，頻域掩蔽，雙耳暗示效益編碼）。因此，Opus適合電臺這種音樂語音混合編碼器。可是因爲Opus的音樂編碼CELT的質量並不突出，因此Opus在雙聲道低速率（24kbps~32kbps左右）效果並不突出。在網站上的demo缺乏鋼琴，爵士，搖滾的demo。更可能是流行音樂和民謠。高頻份量相對弱些。但若是使用Opus有如下要注意事情，音頻碼率高些，不要限制編碼器的模式。另外高通宣稱有OPUS專利，來自大神Ken VOS。
EVS 主要是VoiceAge公司，Dolby公司，Fraunhofer，華爲（北京苗磊兄弟，羨慕大家）聯合開發的USAC編碼器（這裏面也有故事，和技術無關，我就不八卦了），低速率音樂編碼器質量很好，源自dolby和Fraunhofer的HEAACv2技術。可是問題是，目前沒有高效的嵌入式系統可用的編碼器，不支持雙聲道，專利費不便宜哦。主要計劃用在將來的VoLTE中（華爲又要收蘋果錢了哦）。

二、直播中Codec選擇

1）AAC系列與Opus
沒什麼好說的，音樂電臺能夠選擇Opus，主流的仍是AAC，注意，建議立體聲使用HE-AACv2，單聲道選擇HE-AACv1。而不是通常的AAC。HE-AACv1 = AAC + SBR,HE-AACv2 = HE-AACv1+ PS.
AAC的合理編解碼質量是在雙聲道64kbps~128kbps（商用編解碼器和標準參考代碼是不同質量的，請區分）。HE-AACv1的合理編解碼器區間是雙聲道40kbps~64kbps。HE-AACv2的合理編解碼器區間是雙聲道24kbps到48kbps。

三、丟包對抗的幾種辦法

1）重傳：

傳統物理信道傳輸中，不管是802.11仍是3g/4g標準，自己就包含物理層重傳機制，在IP信道中，重傳也是很是有效的方法。
優勢：節省帶寬，按需重傳。
約束條件，RTT時間短

2）FEC：

FEC有不少種，主要特色是主動抗丟包，經過增長冗餘數據實現抗丟包效果。缺點是浪費帶寬。通常的說，只有在丟包大於10%的時候才使用FEC。FEC技術有如下分類方法。

• 不分級的FEC

• 信源FEC

• Inband FEC

• Outband FEC

• 信道FEC

• Read SolomonCode

• DigitalFountain Code

• 分級的FEC

• PLC
  PLC的意義在於當FEC和重傳以後還沒法恢復的時候，經過信號處理的方法對丟失的數據進行補償。

分類：

• 插0法：所謂插0法就是在丟包的位置全添0.

• 預測法，插值法，快慢放（注意，快慢放有反作用，你們不肯意接受這種作法）

• 基於編解碼模型的PLC方法

  • 特色：被動抗丟包。

  • 優勢：靈活不佔帶寬

  • 缺點：根據編解碼器的類型，對抗能力有限
    對低壓縮比的編解碼器，能夠作到比較高的抗丟包效果。對高壓縮比的編解碼器，通常看丟包能力在5%如下。

• 高級PLC算法，盲寬帶帶寬擴展(BWE)，就是把8Khz拓展到16Khz。

7、WebRTC

Webrtc的緣來：WebRTC的前身是GIPS，在GIPS被Google收購以後，google選擇將GIPS的源代碼開源。可是其實不是所有。只能說絕大部分已經開源。
##一、Webrtc適用於什麼條件
包裝開發，知足1對1，P2P，Iphone 通訊，對質量沒有啥要求
二次開發，抽取webrtc的好的部分，本身開發，可是工做量很大
##二、Webrtc的問題

1）P2P的問題

WebRTC使用的是P2P的方法進行網絡傳輸，並宣稱保密性好。P2P在通訊中Skype使用的比較早，有人曾經在網上分析過Skype全球有21個節點。其他都用P2P傳輸。可是這個前提是當時Skype大部分是基於PC+LAN/WIFI網絡。適用於一對一通訊，容易穿透，用戶流量沒限制，CPU穩定。而在Skype向手機普及，在無線網上提供VOIP服務的時候，增長了大量服務器路由。
缺點：佔用別人流量，不適合在多人通訊中，要求網絡穩定。
優勢：適用於demo。

2）Lastmile的問題

在lastmile對抗上，webrtc的對抗過於死板，缺乏對現網的監控與反饋，雖然在webrtc內部有大量的不錯的算法，可是缺乏有機適用，好比，有些參數仍是針對有線網設計的參數。

3）Device 的回聲消除

安卓的碎片化，和回聲消除的固有特色使得WebRTC在移動端沒法知足讓全部機型都處理的很好。

4）若是你想用webrtc開發你要作什麼

架設服務器，監控，運維，客服。

Lastmile網絡對抗，本身作策略AVNM，前面描述了不少種網絡狀態，要靠單一的方法是沒法知足全面作好，須要複雜的數據挖掘，分析，整理再反饋網絡策略參數調整才能夠完成。
端的AV-D/C/P/-M算法，本身要作AV的硬件機型配置，選擇和改進。須要在安卓機型作大量的回聲消除算法改進。

【本文做者】高澤華，11年音樂語音編解碼學習經驗。理解幾十種音頻編解碼標準。前後在中磊電子、士蘭微電子、虹軟科技主導音頻項目。任職YY期間負責語音音頻技術工做。對音頻算法在芯片設計、嵌入式系統、桌面軟件。在互聯網應用和專利分析方面有多年研發經驗和積累。目前負責聲網Agora.io的音頻開發工做。