語音視頻社交背後技術深度解析

你們好，我是即構科技的聯合創始人蔣寧波，今天分享的題目《實時語音視頻技術的深度解析》，但願和你們交流實時音視頻互動的一些技術點。首先簡單自我介紹下，我從2005年到2015年在騰訊工做，前期負責QQ Hummer部分重構項目，後期負責騰訊QQ安全的工做，包括把QQ的安全能力開放給其餘企業使用。2015年聯合創當即構科技，即構科技是提供實時音視頻的雲服務商，致力於提供全球最穩定最高質量的實時語音視頻雲服務，主要產品針對多人實時語音，多人實時視頻，和互動直播。現有的客戶包括映客、花椒、一直播，喜馬拉雅FM，六間房、酷狗直播、自由之戰2和好將來等。算法

今天主要分四塊內容跟你們一塊兒交流，首先是經過兩年大量實時音視頻客戶的合做，看到了行業應用的一些發展趨勢，其次就是實時音視頻互動的技術難點，以及即構科技解決這些問題的思路，最後會分享如何選擇實時語音視頻雲服務商。後端

行業趨勢安全

近幾年，伴隨手機等智能硬件設備以及網絡狀況的提高，實時音視頻獲得愈來愈普遍的應用，在娛樂化方面，從互動直播，到集成音視頻SDK、帶有社交屬性的休閒小遊戲，再到如今音視頻的陌生人社交應用。從15年下半年到16年的千播大戰，基本上,一二線的直播平臺都標配了連麥直播，容許多個主播作實時互動；16年末到17年初，集成了音視頻的社交屬性的休閒小遊戲異軍突起，最典型的就是狼人殺，還有一些棋牌類遊戲；如今最火爆的則是陌生人視頻社交應用，像多人羣聊社交產品Houseparty和青少年社交網絡Monkey等等，並且伴隨美顏、掛件這些圖像處理技術愈來愈成熟，更多的90後、00後等一批互聯網原住民將視頻社交融入到平常生活中。網絡

實時音視頻互動難點併發

對於一個實時互動的音視頻系統而言，存在不少技術難點，我從中摘取幾個比較重要的點：首先是低延遲，若是要知足比較流暢地進行實時互動，那麼單向的端到端的遲延大概要在400毫秒如下才能保證流暢溝通；第二點就是流暢性，你也很難想象在視頻過程當中頻繁卡頓會有良好的互動；第三點是回聲消除，回聲的產生是揚聲器播放的聲音通過環境反射被麥克風從新採集並傳輸給對方，這樣對方就會一直聽到本身的回聲，整個互動過程會很是難受；第四點是國內外互通，隨着如今國內同質化產品愈來愈多，國內的競爭也異常激烈，不少廠商紛紛選擇出海，這時就須要作好海內外的互通；第五點是海量併發，固然這不只僅指實時音視頻了，基本對於任何一款互聯網產品而言都是必需要考慮的難點。負載均衡

難點解決方案機器學習

接下來我將針對上面幾個技術難點，跟你們分享一下咱們即構團隊的解決思路和實踐經驗。ide

• 低延遲學習

首先，若是實時音視頻要保證低延遲，那麼前端和後端的整個鏈條必定要作到極致的，好比前端的一些編碼算法、流控，甚至丟幀、追幀策略等等都要作到足夠好。另外，不一樣的業務場景下，編碼器的選擇也會有所區別，從而會帶來不一樣的編碼延遲，所以不一樣的業務場景能達到的延遲程度也是不同的。

其次，就是對推拉流網絡的選擇，一般的方案是讓須要實時互動的用戶經過核心語音視頻網絡——像BGP這樣的優質節點來作語音視頻傳輸，而對於一些特定場景來講，好比互動遊戲會直播給一些圍觀用戶看，那麼這裏就須要作轉碼、轉協議、甚至混流，再經過內容分發網絡去分發。像 內容分發網絡自己自然就有作就近接入，但對於接入核心語音視頻網絡就須要有智能的調度策略來完成就近接入，以及跨運營商、跨區域的接入，好比能夠採用上次登陸IP、經常使用IP和區域調度，甚至能夠測速再去鏈接，固然網絡調度的策略也須要根據業務羣的分佈仔細規劃，甚至採用多個策略配置權重的方式。

• 流暢性

要實現流暢性也會有不少的技術難點和策略，我主要會介紹其中幾種。第一個是能夠作動態伸縮的JitterBuffer，在網絡較差或者網絡抖動比較劇烈的狀況下，能夠適當增大JitterBuffer，從而下降一點點延遲來對抗抖動。

第二個是快播和慢播技術，在網絡較差的環境，能夠在用戶無感知的條件下稍微下降播放速度，來應對短暫網絡抖動引發的當即卡頓，當網絡恢復能夠加快速度追回來，但這種方式並不是適合全部場景，好比對於節奏要求很是準確的唱歌場景，當播放速度稍微放慢就能夠被感知。

第三個是碼率自適應，也就是以比較合適的碼率作動態傳輸，爲了保證流暢度甚至能夠調整幀率和分辨率。語音視頻引擎會根據當前網絡測速的結果和應用所指望的碼率，動態地調整碼率、幀率和分辨率，最終達到流暢觀看的用戶體驗。

第四個是分層編碼、傳輸控制，在推流端作一些分層的編碼，這樣在拉流端能夠動態根據偵測到的網絡帶寬狀況來拉取不一樣的數據去作渲染。分層編碼容許拉流端取選擇不一樣層次的視頻編碼數據，網絡狀況好的時候，就拉取較多層次的數據；網絡狀況差的狀況下，就拉取基礎層次的數據。

第五個是動態調度，當在推拉流端監測當前推拉流質量比較差，並且即便經過下降碼率、幀率和分辨率等策略已經沒法保證質量，這時就能夠選擇放棄這條鏈路，直接從新作選入、創建鏈接，固然在這個過程當中可能會出現短暫的停頓。

• 回聲消除

首先介紹下回聲消除的原理：對端發送的信號會先給到回聲消除的模塊，做爲未來消除的參考信號，再把信號給到揚聲器播放，揚聲器播放後因爲周圍環境反射造成回聲，與真實的音頻輸入一同被麥克風採集，這時採集到的輸入信號是帶有回聲的，回聲消除模塊會根據前面的參考信號生成濾波抵消掉回聲消後再發送出去。

原理聽起來會比較簡單，但在實際過程當中卻蘊藏着不少的難點，好比回聲消除模塊接收的參考信號與最終被環境反射後的回聲自己就是存在差別的，此外設備也會極大的影響回聲消除，尤爲是國內的安卓機型特別多，好比國內某手機廠商，從麥克風採集音頻數據到提交中間有將近一百毫秒的延遲，這時回聲消除算法如何適應這麼長回聲延遲的手機就很關鍵；再好比不少用戶在直播中都會用外置聲卡，甚至是模擬器，這無形中也會帶來回聲的延遲。除了設備，場地一樣存在很大的相關性，對於普通會議室，設置 40米的回聲延遲可能已經足夠了，但一些大會場這種回聲延遲能達到將近上百米，這也是一種挑戰。

關於回聲消除，其實谷歌開源的WebRTC提供了回聲消除模塊，但WebRTC的設計自己是爲了在PC端實時音視頻互動的場景，在移動端的適應性上就會差一些，尤爲體如今安卓的一些低端機上。而相對來講，蘋果由於總體硬件、軟件全是本身實現的，麥克風、揚聲器也都有聲學模型設計，所以回聲消除的效果會比安卓好不少。即構科技的音視頻引擎都是採用自研，在真機和模擬器等1000多的機型上測試過，均可以作到很好的回聲消除。

• 國內外互通

前面提到不少產品都會選擇出海，包括主打國內市場的產品也會有一些海外用戶，所以流媒體數據和控制信令就要作好跨國的互通，這就須要考慮在全球合理佈置一些中繼節點。

這張圖就是一個典型的中繼續傳，北京用戶和迪拜用戶之間要作視頻溝通，根據就近接入原則他們會分別鏈接當地的節點，而這兩個節點間若是互拉，效果會很是差，這時就須要佈置適合的中繼節點，好比香港、新加坡、日本等等，數據路徑的選擇是須要根據業務側決定的，也就是說在物理鏈路路由之上還要再有一條業務的路由表，須要根據用戶場景制定，包括用戶分佈、用戶訪問頻率、高頻段峯值等等，可能每次的路由都會有所不一樣。

• 海量併發

海量併發是全部互聯網產品都會遇到的問題，這裏就再也不展開，主要要考慮負載均衡，如何平滑擴容，對於沒法覆蓋的地方要作代理調度，甚至須要考慮容災、接入層的設計等等。

如何選擇實時語音視頻雲服務商

實時語音視頻的技術門檻相對比較高，若是依靠本身研發，可能即便會投入不少開發成本也沒法與匹配市場快速發展的節奏。如今實時音視頻雲服務已經十分紅熟，其實不妨「讓專業的人去作專業的事」。而對於實時語音視頻雲服務商的選擇也大體能夠歸爲幾點：

第一點，確定是技術過硬。測試產品質量是很好的選型方法，測試的指標包括延遲時間、回聲消除的效果以及多機型兼容性等等。

第二點，是否被頂級廠商地大規模驗證過。不少系統在小規模併發時看起來質量很好並且很是穩定，但在真實現網環境下一旦大規模併發上來的時候就會出現各類各樣的問題。所以選擇的產品必須得能在真實的複雜網絡中支持大規模併發。

第三點，系統接口要足夠簡單、靈活，能夠保證基礎功能的廠商快速集成，同時也要能知足高端客戶定製化能力的接入。從採集、前處理、編碼、推流、拉流、解碼和渲染一整套流程中每一個環節都是要徹底解耦的，這樣就能夠集成第三方、甚至客戶自身的技術模塊。

第四點是技術服務足夠好，對需求的響應足夠快，並且要有完善的運營支撐體系，能快速定位問題，所以對於監控告警、日誌的上報採集就顯得很是重要。

圖：秒級原始數據

---

活動推薦——RTC Meetup

回首2017，從直播、狼人殺到在線抓娃娃，不斷迭起的風口讓咱們看到，實時音視頻技術已經不斷地應用到各行各業。將來，隨着5G 的即將到來、新技術如機器學習算法在音視頻技術中的應用，能夠預見，實時音視頻必然將更大規模的應用到更多的領域。

RTC Meetup邀請了4位實時音視頻領域的技術大咖：

郭亮  騰訊音視頻實驗室技術負責人

關旭  即構科技音視頻引擎核心開發人員

曹木勇  騰訊GVoice/GVideo技術負責人

李大帥  深圳奔邁科技總經理、CTO

活動報名請戳：http://www.huodongxing.com/event/1418096252900