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

一、一個典型的IP通信模型

二、Server2Server技術分類

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

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

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

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

在很多時候，由於運營商之間的結算和有限帶寬的問題。運營商之間的網絡不穩定。

3、不同國家之間：

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

• 中美，中歐

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

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

三、Server2Device——Lastmile技術簡介

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

首先我們定義下什麽是丟包：沒按時到的包就是丟包。一個包應該在某個時間點到，但它晚到了，即使來了但是晚了，也叫丟包。因為播放的這段時間已經過去了，即使放了，體驗也不好。從整個網絡上看，丟包一定有時限，否則，都通過反復重傳方法，一定能送達一個包。

Server到達device這塊還可以分以下兩種通路。

1、Server經過基站到Device

可以分為以下幾種情況：

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

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

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

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

2、Server經過家用路由器到Device

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

四、Device技術簡介

AVDM，AVPM，AVCM，AVNM

1、AVDM(Audio Video Device Module)：

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

2、AVPM(Audio Video Processing Module)

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

3、AVCM(Audio Video Coding Module)

編解碼器的選擇和處理，視頻包括是選擇VP8、VP9，還是選擇264、265，是用硬件還是用軟件，是否涉及專利問題。選擇硬件會遇到什麽問題，選擇軟件會遇到什麽問題，為什麽用硬件會遇到很多參數不能配置的問題。是否需要和硬件廠商配合。安卓碎片化導致的硬件支持問題。高通的硬件支持有什麽問題，mtk的硬件支持有什麽特點。硬件支持是否還要交專利費。

4、AVNM

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

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

以上每個點都能講或者寫很多內容，本文只做簡單梳理、點到為止，以後再做專題分析。

五、IP通信的幾種結構

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

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

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

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

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

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

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

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

1、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中（華為又要收蘋果錢了哦）。

2、直播中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。

3、丟包對抗的幾種辦法

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

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

分類：

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

• 預測法，插值法，快慢放（註意，快慢放有副作用，大家不願意接受這種做法）

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

  • 特點：被動抗丟包。

  • 優點：靈活不占帶寬

  • 缺點：根據編解碼器的類型，對抗能力有限對低壓縮比的編解碼器，可以做到比較高的抗丟包效果。對高壓縮比的編解碼器，一般看丟包能力在5%以下。

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

七、WebRTC

Webrtc的緣來：WebRTC的前身是GIPS，在GIPS被Google收購之後，google選擇將GIPS的源代碼開源。但是其實不是全部。只能說絕大部分已經開源。
##1、Webrtc適用於什麽條件
包裝開發，滿足1對1，P2P，Iphone 通信，對質量沒有啥要求
二次開發，抽取webrtc的好的部分，自己開發，但是工作量很大
##2、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的音頻開發工作。

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