編者按：音視訊技術的歷史可能要追溯到19世紀末——特斯拉與愛迪生的偉大時代。直到今天，他們的發明依然伴隨我們生活的每時每刻。2018年音視訊技術將有哪些突破？來自學霸君的資深架構師袁榮喜從編解碼器、客戶端、傳輸網路、動態緩衝區以及媒體處理技術幾個方面解析實時音視訊技術。展望2018，區塊鏈、AI、WebRTC、AV1將成為關鍵詞。

本文由LiveVideoStack與《程式設計師》雜誌聯合策劃，並將在《程式設計師》雜誌2018年1月刊釋出。最後，感謝《程式設計師》雜誌主編盧鶇翔的建議與高效配合。

文 / 袁榮喜

策劃 / LiveVideoStack，《程式設計師》雜誌

責編 / 盧鶇翔

實時音視訊技術是源於早期的VoIP通訊，隨著後來網際網路的發展程序，這項技術2003年被Skype引入到PC桌面系統，開啟了整個實時音視訊技術新紀元。經過15年的進化，基於PC上的實時音視訊技術日漸成熟，也湧現了像WebRTC這樣的開源專案。但隨著近幾年移動網際網路和4G的興起，實時音視訊領域有了更廣泛的應用，引來了新的技術難題和挑戰。經過2016年直播大戰後，音視訊應用得到了使用者的認可，直接促成了2017年實時音視訊應用的大爆發，在娛樂方面出現了像狼人殺、陌生人視訊社交、線上抓娃娃等風口；在協作應用領域出現了Slack和Zoom等多人遠端協作應用；在行業應用上也有很大的突破，例如像VIPKID、學霸君1V1等強勁的線上教育產品。在蘋果8月份宣佈新一代iOS瀏覽器Safari支援WebRTC後，實時音視訊技術成為了時下熱門技術體系。

但實時音視訊相關技術門檻非常高，很多細節並不為人所知，其中涉及到平臺硬體、編解碼、網路傳輸、服務併發、數字訊號處理、線上學習等。雖然技術體系繁多，但總體上歸納兩類：1對1模式和會議模式。我從這兩個分類對實時音視訊相關技術做簡單介紹，主要有以下幾方面： 

• 編解碼器

• 客戶端上傳

• 實時傳輸網路

• 動態緩衝區

• 媒體處理技術

編解碼器

談到視訊編碼器，就會想到MPEG4、H.264、H.265、WMA等等，但不是所有的視訊編碼器都可以用來作為實時視訊的編碼器，因為實時視訊編碼器需要考慮兩個因素：編碼計算量和位元速率頻寬，實時視訊會執行在移動端上，需要保證實時性就需要編碼足夠快，位元速率儘量小。基於這個原因現階段一般認為H.264是最佳的實時視訊編碼器，而且各個移動平臺也支援它的硬編碼技術。

• H.264/ AVC 

H.264是由ITU和MPEG兩個組織共同提出的標準，整個編碼器包括幀內預測編碼、幀間預測編碼、運動估計、熵編碼等過程，支援分層編碼技術（SVC）。單幀720P解析度一般PC上的平均編碼延遲10毫秒左右，位元速率範圍1200 ~ 2400kpbs，同等視訊質量壓縮率是MPEG4的2倍，H.264也提供VBR、ABR、CBR、CQ等多種編碼模式，各個移動平臺相容性好。

• VP8/VP9 

除H.264以外，適合用於實時視訊的編碼器還有Google提供的VP8，VP8採用了H.264相似的編碼技術，計算複雜度和H.264相當，不支援SVC，相同視訊質量的壓縮率比H.264要小一點，不支援B幀。而後Google又在VP8的基礎上研發了VP9，官方號稱VP9在相同視訊質量下壓縮率是VP8的2倍，對標的對手是H.265，VP9已經嵌入到WebRTC當中，但VP9編碼時CPU計算量比較大，對於VP9用於實時視訊我個人持保留意見。不管是VP8還是VP9硬編方式只有Android支援，iOS和其他的移動平臺並不支援。

• 音訊編碼器

實時音視訊除了視訊編碼器以外還需要音訊編碼器，音訊編碼器只需要考慮編碼延遲和丟包容忍度，所以一般的MP3、AAC、OGG都不太適合作為實時音訊編碼器。從現在市場上來使用來看， Skype研發的Opus已經成為實時音訊主流的編碼器。Opus優點眾多，編碼計算量小、編碼延遲20ms、窄帶編碼-silk、寬頻編碼器CELT、自帶網路自適應編碼等。

圖1：語音編碼器編碼延遲與位元速率對比

客戶端推流

實時音視訊系統都是一個客戶端到其他一個或者多個客戶端的通訊行為，這就意味著需要將客戶端編碼後的音視訊資料傳輸到其他客戶端上，一般做法是先將資料實時上傳到伺服器上，伺服器再進行轉發到其他客戶端，客戶端這個上傳音視訊資料行為稱為推流。這個過程會受到客戶端網路的影響，例如：Wi-Fi訊號衰減、4G弱網、擁擠的寬頻網路等。為了應對這個問題，實時音視訊系統會設計一個基於擁塞控制和QoS策略的推流模組。

• 擁塞控制

因為客戶端有可能在弱網環境下進行推流，音視訊資料如果某一時刻發多了，就會引起網路擁塞或者延遲，如果發少了，可能視訊的清晰不好。在實時音視訊傳輸過程會設計一個自動適應本地網路變化的擁塞控制演算法，像QUIC中的BBR、WebRTC中GCC和通用的RUDP。思路是通過UDP協議反饋的丟包和網路延遲（RTT）來計算當前網路的變化和最大瞬時吞吐量，根據這幾個值調整上層的視訊編碼器的位元速率、視訊解析度等，從而達到適應當前網路狀態的目的。

• QoS策略

客戶端推流除了需要考慮網路上傳能力以外，還需要考慮客戶端的計算能力。如果在5年前的安卓機上去編碼一個解析度為640P的高清視訊流，那這個過程必然會產生延遲甚至無法工作。為此需要針對各個終端的計算能力設計一個QoS策略，不同計算能力的終端採用不同的視訊編碼器、解析度、音訊處理演算法等，這個QoS策略會配合擁塞控制做一個狀態不可逆的查詢過程，直到找到最合適的QoS策略位置，圖2是一個實時音訊的QoS策略遷移過程例項。

圖2：實時語音的QoS狀態遷移

傳輸路徑技術

在前面我們對實時音視訊歸納為：1V1模式和1對多模式，這兩種模式其實傳輸路徑設計是不一樣的。1V1模式主要是怎麼通過路由路徑優化手段達到兩點之間最優，這方面Skype首先提出基於P2P的Real-time Network模型。而1對多模式是一個分發樹模型，各個客戶端節點需要就近接入離自己最近的server伺服器，然後在server與server構建一個實時通訊網路。

• P2P前向收斂技術

對於1V1模式的實時音視訊通訊，很多時候我們以為兩點之間直連是延遲最小質量最好的通訊鏈路，其實不是。整個骨幹網的結構並不是網狀，而是樹狀的，這個從同城網通電信之間互聯的質量可以得出結論，如果涉及到國際之間互聯更是複雜無比。一個好的1V1實時音視訊系統會設計一個對等多點智慧路由的傳輸演算法，就是通過多節點之間的動態計算延遲、丟包等網路狀態來進行路徑選擇，這是個下一跳原則的選擇演算法，只要保證每個節點自己傳送包的下一跳的延遲和丟包最小，那麼整個傳輸路徑就是最小最優，一般TTL小於4。尋找下一跳的過程是一個P2P節點前向收斂技術，它需要一個函式f(x)來做收斂。圖3是一個傳統1V1和基於P2P relay的1V1對比示意圖。

圖3：P2P多路徑傳輸示意圖

• proxy傳輸技術

對於1對多模式的實時音視訊通訊，需要一箇中心server來控制狀態和分發流資料，但參與通訊的節點不都是對中心server網路友好，有可能某些節點連不上中心server或者丟包延遲很大，無法達到實時通訊目標需求。所以一般會引入就近proxy機制來優化傳輸網路，客戶端節點通過連線距離最近的proxy到中心server。這種方式不僅僅可以優化網路，還可以起到保護中心server的作用。

圖4：proxy傳輸模式示意圖

• 分段計算

不管是P2P relay模式的1v1，還是就近proxy的1V多模式，在資料傳輸過程會做各種傳輸補償來應對丟包，例如：FEC、ARQ等，如果進行ARQ還需要對重傳的資料做臨時儲存。這裡遵循的是分段計算的原則，這個原則大致是：每一段網路上一跳節點必須獨立計算到下一跳節點之間的丟包、延遲，並將接收到資料cache在記憶體中，根據這段網路的狀態啟用對應的FEC、ARQ和路由選擇策略，不影響其他分段傳輸策略。

圖5：分段計算與網路節點示意圖

• WebRTC閘道器

在實時音視訊系統中需要在Web上進行實時通訊，各個瀏覽器都已支援WebRTC，所以WebRTC是Web上實時音視訊通訊的首選。但WebRTC是基於瀏覽器的客戶端點對點系統，並沒有定義多路通訊標準和服務中轉標準，不管是1V1模式還是1對多模式，需要引入WebRTC閘道器來接入自定義的實時系統。閘道器負責將WebRTC的SDP、ICE、STUN/TURN、RTP/RTCP翻譯成自定義系統中的對應協議訊息，實現無縫對接WebRTC。WebRTC很多類似的開源閘道器，例如：licode、janus等。

動態緩衝區

在實時視訊的播放端會有一個自動動態伸縮的JitterBuffer來緩衝網路上來的媒體資料，為什麼要這個JitterBuffer呢？因為TCP/IP網路是一個不可靠的傳輸網路，音視訊資料經IP網路傳輸時會產生延遲、丟包、抖動和亂序，JitterBuffer可以通過緩衝延遲播放來解決抖動亂序的問題。但JitterBuffer如果緩衝時間太長，會引起不必要的延遲，如果緩衝時間太短，容易引起音視訊卡頓和抖動。所以JitterBuffer在工作的時候會根據網路報文的抖動時間最大方差來動態確定緩衝時間，這樣能在延遲和流暢性之間取得一個平衡。

JitterBuffer除了緩衝解決抖動和亂序的問題以外，為了延遲和流暢性之間的制約關係，它還需要實現快播和慢播技術，當JitterBuffer中資料時間長度小於確定的抖動時間，需要進行慢播，讓抖動緩衝區資料時間和抖動時間齊平，防止卡頓，當JitterBuffer中的資料時間長度大於確定的抖動時間，需要進行快播，接近抖動時間，防止累計延遲。

媒體處理

• 回聲消除

在實時音視訊系統中，回聲消除是一個難點，儘管WebRTC提供了開源的回聲消除模組，但在移動端和一些特殊的場景表現不佳。專業的實時音視訊系統會進行回聲消除的優化。回聲消除的原理描述很簡單，就是將揚聲器播放的聲音波形和麥克風錄製的波形進行抵消，達到消除回聲的作用。因為回聲的回錄時間不確定，所以很難確定什麼時間點進行對應聲音資料的抵消。在專業的回聲消除模組裡面通常會設計一個逼近函式，通過不斷對輸出和輸入聲音波形進行線上學習逼近，確定回聲消除的時間差值點。如圖6所示。

圖6：回聲消除模型與逼近函式

回聲消除整個過程對CPU計算有一定的要求，尤其是在移動端裝置上，所以在設計回聲消除模組的時候會將回聲消除演算法設定幾個計算等級，不同的等級不同的CPU計算量，根據執行裝置的效能來做策略調節。

• 人臉與AI

直播時代人臉美顏和特效已經不再是稀奇的功能了，這得益於AI深度學習和神經網路的發展。值得一提的是，已經有通過對抗神經網路進行人臉替換的技術，這個技術是通過CycleGAN演算法模型將視訊中每個畫素替換成目標畫素，以此來達到偷樑換柱的目的。未來一個普通主播替換成明星臉的現象會越來越多。

總結與思考

實時音視訊領域涉及的技術眾多，有控制網路延遲的，有抗丟包的，有用於增強流暢度的，有用於減少成本的。這其中還有很多懸而未決的問題，例如跨國零延遲實時傳輸、大規模實時分發、超高清實時、實時VR/AR等。這個領域的技術還在不斷髮展，隨著硬體和演算法的不斷升級，這些問題正在逐步被解決。在這裡簡單對未來這方面技術做個展望。

2017年的新一代iPhone上已經嵌入了H.265的硬編模組，接下來很多手機廠商都會植入H.265的硬編模組來提高手機的競爭力。這一局面將加快H.265在實時音視訊的應用。除了H.265外，Google聯合各個瀏覽器廠商正在加緊研發AV1新一代網際網路視訊編碼器，預計在2018年放出alpha版測試，AV1在專利費和瀏覽器相容上有很大的優勢，這是個非常值得期待的事。

在實時音視訊傳輸方面也正在與當下流行的AI和深度學習結合，基於機器學習的擁塞控制演算法已經在實驗階段，基於大資料和神經網路的實時傳輸鏈路優化也在各大雲廠商中開展，我個人看好利用AI和深度學習技術來進行網路調優、傳輸路徑優化和時延控制，這塊在未來幾年會有相對應的突破。而與區塊鏈的結合可能更多是基於成本上的考慮，例如迅雷的玩客幣、賺錢寶等，這類技術方向會催生出新一代的CDN實時分發網路。

行業應用上，線上教育會繼續在師生注意力、教育效果上對實時音視訊上做深挖，很有可能會引入實時AR/VR來增強使用者體驗和認知感覺。實時音視訊正在成為計算機視覺的下一個發展方向，會持續輸出到IoT、毫秒級實時視訊監控等行業領域。

關於作者

袁榮喜，學霸君資深架構師，16年的C程式設計師，好求甚解，善於構建高效能服務系統和系統性能調優，喜好解決系統的疑難雜症和debug技術。早年痴迷於P2P通訊網路、TCP/IP通訊協議棧和鑑權加密技術，曾基於P2P super node技術實現了視訊實時傳輸系統。2015年加入學霸君，負責構建學霸君的智慧路由實時音視訊傳輸系統和網路，解決音視訊通訊的實時性的問題。 近幾年專注於儲存系統和併發程式設計，對paxos和raft分散式協議饒有興趣。尤其喜歡資料庫核心和儲存引擎，堅持不懈對MySQL/innoDB和WiredTiger的實現和事務處理模型進行探究。熱衷於開源，曾為開源社群提過些patch。業餘時間喜歡寫技術長文，喜歡讀唐詩。

LiveVideoStack招募全職技術編輯和社群編輯

LiveVideoStack是專注在音視訊、多媒體開發的技術社群，通過傳播最新技術探索與應用實踐，幫助技術人員成長，解決企業應用場景中的技術難題。如果你有意為音視訊、多媒體開發領域發展做出貢獻，歡迎成為LiveVideoStack社群編輯的一員。你可以翻譯、投稿、採訪、提供內容線索等。

通過[email protected]聯絡，或在LiveVideoStack公眾號回覆『技術編輯』或『社群編輯』瞭解詳情。