展望2018音視訊技術：AV1，AI，區塊鍊，WebRTC

編者按：音視訊技術的曆史可能要追溯到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公衆号回複『技術編輯』或『社群編輯』了解詳情。