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

在 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 網絡屬於徹底分佈式網絡，分佈在又拍雲兩百多個節點，四千臺服務器上。只須要接入又拍雲任意邊緣服務器，就能夠作到自主服務，自動選擇出一條甚至數條路徑，讓用戶與通信網中任何地點的人交互。

又拍雲 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 直播技術解析