即時音視頻互動系列（下）：基於 WebRTC 技術的實戰解析

標籤：mtk   webrtc   互動   targe   電話   技術分享   視頻   服務商   品牌   

在 WebRTC 項目中，又拍雲團隊做到了覆蓋系統全域，保證項目進程流暢。這牽涉到主要三大塊技術點：

• 網路端、服務端的開發和傳輸演算法

• WebRTC 協議中牽扯到服務端的應用協議和信令服務

• 用戶端iOS、安卓 H.264 編解碼技術

△ WebRTC 技術點

即時音視頻互動必須遵守三大點

 

• 必須基於 UDP 協議，否則不要談即時

     因為 TCP 協議的重傳機制（傳輸保障）會導致累積延遲問題，用 UDP 協議沒有傳輸保障機制，但需要自行完善丟包容錯邏輯。

又拍雲音視頻互動方案是基於UDP 協議，使用 TCP 協議無法保障即時性。

TCP 協議有包重傳機制，保證傳輸內容100%傳輸到目的地，這個特性導致延時增加。當然，由於UDP協議沒有包重傳機制，需要完善業務的容錯性。目前來說，UTUN 網路提供的兩種配置，都可以保證資料100%傳輸。

在極差的網路狀態下，可以選擇容忍丟包，使用演算法保障90%以上的資料包正常到達，以此達到200ms以內延遲。

UDP協議相比TCP協議具有多鏈路傳輸的優勢。

TCP協議只支援單一鏈路傳輸。當連麥、音畫同時需要傳輸時，TCP協議只有一條通道進行資料轉送。而通過UDP協議，音視頻可以通過兩個節點將資料一分為二來傳輸，A路傳輸50%資料包，B路傳輸50%資料包。終端收到兩路資料流，再合并放到應用程式層做解碼處理。

• 考慮多終端適配，使用 WebRTC 協議

用戶端網路跨地區和跨電訊廠商訊號很差，所以不能使用 P2P 模式。目前包括蘋果Safari 在內的所有的案頭端瀏覽器都已支援 WebRTC 協議。

網路層使用 P2P 模式無法解決跨地區、跨 ISP 的跨電訊廠商網路問題，會導致延時過高的情況產生。如果一直糾結於P2P模式，那麼QOS碼率控制、包容忍等問題就無法在演算法上有所突破。

• 雲端服務化

單機、單機房存在硬體瓶頸，唯有雲端服務化才能按需做到橫向擴充。

隨著使用者量的提升，單台伺服器所能支撐的並發量直播有限，RTMP Server、WebRTC Server一般八核伺服器能承受的並發量只有2000~4000路，單機房也會成為硬體瓶頸，而公用雲端能承受幾十萬甚至上百萬的數量壓力，所以機房中不能存在單點，必須是雲端服務化分布式的。

雲端服務化非常重要，上文提到的 UTUN 網路屬於完全分布式網路，分布在又拍雲兩百多個節點，四千台伺服器上。只需要接入又拍雲任意Edge Server，就可以做到自主服務，自動選擇出一條甚至數條路徑，讓使用者與通訊網中任何地點的人互動。

又拍雲 WebRTC 架構中遇到的經驗和問題

 

     又拍雲 WebRTC 相比外部的 WebRTC 有較大的差別。即使你在同一個地方、同一個服務商、同一個無線訊號下，又拍雲都沒有使用P2P模式，都是通過雲端服務來進行網路傳輸的。

        我們嚴格遵循官方標準搭建包括服務端、用戶端在內的 WebRTC 體系。目前 WebRTC 版本為可變性非常大的1.0版本，未來該技術可能會有革命性的迭代。如果採用自研的方式，會有無法跟進版本技術更新的風險。再者如果完全自主編寫 Server 端或者用戶端勢必要投入非常大的精力和研發時間。

       因此又拍雲選擇緊跟官方的步伐，無論官方有何種bug修複，都選擇同步更新。

又拍雲在實踐中遇到的問題：

• 當 iOS 端使用新版本 WebRTC 時，由於音頻處理部分導致的 Bug，會導致 CPU 佔用率過高；

• 服務 Server 端由於編碼傳輸時 WebRTC 是可變碼率、可變幀率的，但是核心代碼在進行傳輸時卻使用了固定幀率操作，時間戳記不一致的 Bug 導致了音視頻不同步的情況，聲音與畫面不同步最大延時可以達到數十秒，不斷累積。為瞭解決這個 Bug 需要把視頻時間戳記進行修正，統一使用音訊時間戳記，來保證音視頻同步；

• Android 端不支援高通外的晶片硬解碼，又拍雲在近期把各個 Android 端編解碼功能完善，目前已經能夠適配華為、MTK、三星等品牌的機型；

• 目前用戶端解碼能力有限，會話人數最好控制在8個人以內；

• 自動根據參與人數控制總頻寬在2Mbps以內；

• 美顏、濾鏡等功能的接入會增加延遲，加入額外功能不能過度消耗用戶端 CPU 資源。

音視頻互動最大的痛點——業務信令

 

目前業務信令還沒有一套完整的解決方案，業務信令在 WebRTC 中雖然是開源的，但是沒有形成標準的信令協議，這個部分需要我們自行構建。

架構網路電話情境時，牽扯到三個信令：呼叫、等待接聽、通話。

但是實際中會有更多信令，假設一個會議情境，A邀請參會B，A會設定多個邀請途徑：1.A直接將B拉到會議室；2.A把會議室號碼給B，B自行進入；3.A配置房間許可權控制，需要得到授權才能進入房間等。隨著業務的發展，業務信令會不斷增加，我們需要構建一套完善的信令體系顯得非常重要。

我們在編寫信令系統時，把信令系統分成了兩類：1.底層系統信令，2.公用業務信令。

底層系統信令只需編寫公用業務信令的總通道協議和 API 介面，讓應用程式對接，將業務信令進行統一標準化。比如在房間裡，發送一條廣播給所有參會者的業務信令S，而業務信令S只想傳達給B，但是C在同一個會議室也聽到了，C會選擇性的對業務信令S忽略以此達成這個業務功能。

 

目前來說必須面臨的現實問題：

 

1.用戶端硬體效能未能支援高清碼率：多人互動不可能做到720P解析度，一般來說都是在320P或者460P解析度。一般手機因為用戶端的解碼能力支撐不了多路高清解碼，達到6路以上碼率只能做到300K以下；

2.硬編解碼相容性差：Android 機型太多，僅能有限支援H.264硬編解碼，同時iOS和Android 端均不支援 H.265 硬編解碼；

3.手機發熱、耗電量大：參加會議iPhone電量支撐兩、三個小時。案頭端耗電、發熱最嚴重，測試時使用Chrome硬解碼電量只能支援兩個小時。

以上三點是目前整個業內所都要面臨的最大的問題，只能等待終端的解碼能力提升，相信到明年手機解碼能力就可以支援多路高清互聯。

 

相關閱讀：

即時音視頻互動系列（上）：又拍雲UTUN網路詳解

WebSocket+MSE——HTML5 直播技術解析

即時音視頻互動系列（下）：基於 WebRTC 技術的實戰解析