1. 程式人生 > >將WebRTC用於多人音視訊通訊

將WebRTC用於多人音視訊通訊

       WebRTC非常適合點對點(即一對一)通訊。 但是,當我與客戶討論超出一對一(即一對多或多對多)的解決方案和服務時,問題就出現了:“我應該採用哪種架構?”。 有些服務提供商希望複用他們網路中的組播支援(我們正在為此嘗試做一些實驗),有些正在探索基於聯播(simulcast)的解決方案,還有一些正在考慮像MCU /Mixer這樣的集中式解決方案,而其中一些 只是願意通過使用基於Mesh的技術將負擔放在端點(endpoint)上。

       儘管能實現WebRTC多人音視訊的方案,該技術最流行的用途不侷限於多方視訊會議場景。不要以為只是傳統的音視訊會議室,更多的情況包括:智慧硬體、ipcamera、線上課堂,實時直播等。在每種情況下,核心功能都能夠將來自多個來源的媒體流分配到多個目的地。因此......如果您是服務提供商,您如何使用WebRTC端點實施多方拓撲?
       根據您的要求,有幾種不同的架構可能是合適的。這些架構基本上圍繞兩個方面:
☆集中式 VS 點對點(P2P)
☆Mixing VS Routing
       我將在這裡描述最受歡迎的解決方案。如果您需要更深入地瞭解協議含義和實施細節,您可以在

RTP拓撲IETF文件中找到所有相關資訊。

Mesh解決方案
       Mesh方法是最簡單的解決方案。它在新的WebRTC服務提供商中很受歡迎,因為它不需要架設伺服器。該體系結構基於從每一個傳送者建立多個一對一的資料流到每一個接收者。


       即使看起來效率低下,實際上它也是非常有效的,並且提供了儘可能低的延遲,併為根據實際情況為每個接收者提供獨立的位元率。
       “唯一”問題是該解決方案需要大量的上行鏈路頻寬來同時向所有目的地傳送媒體流,而現有的瀏覽器實現需要大量的CPU功率來並行地對視訊進行多次編碼。

Mixer解決方案
       Mixer是多人視訊會議的傳統解決方案,並且已經使用了多年,取得了巨大成功。這個成功歸功於它在終端(endpoint)中需要最少的成本。 該體系結構基於中心點與每個參與者保持單一的一對一流。然後,中央元件接收並混合每個傳入的音訊和視訊流,為每個參與者生成一個單獨的流。視訊會議行業中這些集中式元件的一個常見術語是多點控制單元(MCU)。實際上,使用MCU通常是指Mixer解決方案。


       Mixer是與老舊裝置互操作性非常好的解決方案。它們還允許全位元率適應,因為Mixer可以產生不同的輸出流,給每個接收者提供不同的質量。Mixer解決方案的另一個優勢是它可以在裝置中利用硬體解碼,只要裝置具有硬體解碼能力。
       主要的缺點是MCU的成本。另外,由於混合需要解碼和重新編碼,這會引入額外的延遲和質量損失。最後,轉換和合成可能在理論上導致應用程式UI的靈活性較低(儘管此問題有解決方法)。

Router解決方案
       Router(或Relay)因H.264 SVC基礎架構變得普及,並且這種架構被大多數新的WebRTC平臺所使用,這些平臺在沒有任何老舊裝置。該體系結構基於中心點接收來自每個傳送者的流,並向每個參與者傳送流。這個中心點只能進行資料包檢測和轉發,而不會對流媒體進行昂貴的編碼和解碼。常見術語是SFU。


       Router提供了一種便宜且可擴充套件的多方解決方案,與傳統調Mixer解決方案相比,在保證視訊質量的前提下具有更低的延遲。
       另一方面,這個方案的行業經驗較少,將流適配到不同的接收者變得棘手。我們需要在終端中支援生成多種不同的流,這些流隨後可以在路由器中被選擇性地轉發。

三種架構的流量對比


我們該用那種架構?
       不幸的是,沒有簡單的答案。事實上,一些商業解決方案包括對所有這些解決方案的支援,以優化不同客戶的使用。但是,這裡有一些一般性的經驗法則。
1.如果您僅提供音訊服務,或者需要與傳統裝置互操作,那麼Mixer架構可能最適合您。另外,如果基礎設施的成本不是問題,並且參與者具有異構連線,這可能是一個很好的解決方案。
2.假設你提供企業級服務,且有較好的寬頻和高效的硬體(即一個企業內部服務),並且參與者數量有限,那麼您可以使用Mesh體系結構獲得良好結果。
3.一般而言,如果您提供大規模服務,則應優先考慮Router方案。歸根結底,Router解決方案最接近於將智慧置於網路邊界的Internet模式,以在構建終端使用者應用程式時實現更好的伸縮性和靈活性。

WebRTC中缺少什麼?

       即使有商業和免費的解決方案在WebRTC上提供多方服務,仍然存在需要在基礎技術中解決的問題,以實現更好的使用者體驗。這些包括:
1.改進了音訊處理和編碼,特別是聲學回聲消除和噪聲抑制演算法。
2.更先進和靈活的擁塞控制,允許開發人員即時修改流的引數,比如位元率,質量或視訊解析度。
3.simulcast和分層視訊編碼支援獨立地將原始視訊流適配到每個接收者,而無需昂貴的程式碼轉換。
       總而言之,我們有能力開始基於WebRTC技術為我們的客戶提供多方服務。隨著標準的發展,隨著更多API的提供,以及隨著更多瀏覽器中更好的實現的出現,基於網路的視訊會議的未來變得更加有前途。