淺談多人音視頻的傳輸架構

在實際的多人音視頻通訊場景中,1 對 1 通訊只是諸多場景的一種。而在教育或者會議的場景中,更多是 1 對多或者是多對多通訊。綜合目前多方通信方案來看,基本都是以下三種架構方案:Mesh 架構、MCU 架構、SFU 架構。

一、Mesh 架構

如上圖所示:5 個瀏覽器,兩兩建立 p2p 連接,每個瀏覽器與其它 4 個建立連接,總共需要 10 個連接,整個傳輸形成一個網格拓撲結構。如果每條連接佔用 1m 帶寬,則每個端上行需要 4m,下行帶寬也要 4m,總共帶寬消耗 20m。他們通過 STUN 服務進行穿越,因此不需要媒體服務,每個瀏覽器上要處理音視頻 “編碼 / 解碼”,一般這種架構只能支持 4-6 人左右,不過優點也很明顯,沒有中心節點,實現很簡單。

二、MCU (MultiPoint Control Unit)

如上圖所示:每個瀏覽器僅與中心的 MCU 服務連接,有這個中心服務負責處理所有的視頻編碼、轉碼、解碼、混合等複雜邏輯。而這個處理過程如下圖所示:

  1. 接收發送端發送的音視頻流。

  2. 將音視頻流的數據進行解碼。

  3. 對於視頻流,要進行重新佈局,混合處理。對於音頻流,要進行混音、重採樣處理。

  4. 將混合後的音視頻進行重新編碼。

  5. 發送給接收端的瀏覽器。中心化的統一處理流程,各端表現更加一致和好處理。而從寬帶使用上看,因爲每個瀏覽器只要 1 個連接,所以整個網絡僅消耗 5 個連接,帶寬佔用 (包括上行、下行)共 10m。從實踐上說,這個架構可以支持更多的人同時音視頻通訊,比較適合多人會議的場景。

三、SFU (Selective Forwarding Unit)

如上圖所示:每個瀏覽器與中心 SFU 服務連接,但與 MCU 服務不同的是,SFU 服務只負責轉發,所以服務器的壓力會低很多。每個瀏覽器用一個上行連接傳輸自己的音視頻,另外還要有 n-1 個連接用於下載其它音視頻數據。所以總連接數爲 5*5,消耗的帶寬也是最大的,如果每個連接 1M 帶寬,總共需要 25M 帶寬。相比 MCU,SFU 在結構上相對簡單很多,只是接收流然後轉發給其他人。這也帶來了其他好處:比如根據帶寬和網絡延時,單獨調整音視頻的碼率等。另外也能靈活調整畫面佈局。

該用哪種架構:

一般建議:如果規模不大 (5 人以下) Mesh 框架就夠用了,畢竟實現簡單;如果 50 人以下,且帶寬有限,選擇 MCU 比較適合;如果規模更大,且帶寬良好,SFU 相對更適合。

但在互聯網 5G 時代,要求更個性化的體驗(美顏,更個性化的控制等等),更大的規模的用戶同時在線人數。總的來說 SFU 架構更適合互聯網時代。隨着 5G 技術的推廣,可以預見帶寬越來越不是問題,所以 SFU 在未來,可能會更有優勢。

參考文章:

WebRTC Multiparty Video Alternatives, and Why SFU is the Winning Model

WebGlossarySFU

WebRTC Media Servers – SFUs vs MCUs

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/BmhdpYaiAdFZq7LKFiK7hg