所周知，WebRTC非常適合點對點（即一對一）的音視頻會話。然而，當我們的客戶要求超越一對一，即一對多、多對一設置多對多的解決方案或者服務，那么問題就來了：“我們應該采用什么樣的架構？” 。簡單的呢有人會考慮copy多個p2p就完成了多人之間的會話，可并沒有考慮到到來的問題：cpu、內存、尤其是流量問題；傳統的解決方案是MCU服務器，利用服務器硬件的能力去mix音視頻，然后傳給各個參與者，這能到達預想的，這個亦能到達我們的需求；使用基于網狀拓撲結構的結構可能是前兩者的折中之選。

盡管能實現WebRTC多人音視頻的方案，該技術的最流行的用途不局限于多方視頻會議場景。不要以為只是傳統的音視頻會議室，更多的情況包括：智能硬件、ipcamera、在線課堂，實時直播等。在每一種情況下，服務器的能力是能夠從多個源的媒體流分發到多個客戶端。所以...如果你是一個服務供應商如何才能在實現支持WebRTC的多方拓撲結構？

有幾種不同的架構根據您的要求，可能是合適的。這些架構基本上他們圍繞二點：

§?集中VS對等網絡（P2P）

§?混合VS路由。

我將在這里介紹最流行的解決方案。如果你需要去深入到協議的影響和實施細則的架構，你可以找到所有的相關信息，RTP拓撲IETF文檔。

Mesh解決方案

Mesh方法是最簡單的解決方案。因為它不需要假設任何服務器，而且直接使用成熟的WebRTC傳輸方案。該體系結構基于從每一個發送者創建多個一對一的數據流到每一個接收端。

?

Mesh解決方案

即使它看起來像一個低效的解決方案，在實踐中是非常有效的，并且延遲最低，每個接收端都會根據實際情況產生不同的比特率。

唯一的問題是，這種解決方案需要大量的上行帶寬將媒體流同時發送至所有目的地，現有的設備實現所需的CPU功率會顯著上升。

Mixer解決方案

Mixer的做法是多人視頻會議的傳統解決方案，并且使用多年取得了巨大成功。這一成功可以歸功于它需要客戶端更少消耗這一事實。該架構基于具有中心點保持與每個參與者一對一的流的特性。中心元件接收并混合每個傳入的音頻流和視頻流，以合成一個單一的流出到每一個參加者。在視頻會議行業對于這些集中元件的一個常見術語是多點控制單元（MCU）。在實踐中，使用一個MCU的通常是指一個混合器容器。

?

Mixer解決方案

混頻器是供傳統設備操作間很好的解決方案。它們還允許全位速率適配，因為混頻器可以產生不同的輸出流，所以每個接收器有不同的品質。混合器解決方案的另一個優點是它可以利用硬件設備編解碼。

主要缺點是在MCU的基礎設施成本高。此外，由于混合需要解碼和再編碼，這引入額外的延遲和質量的損失。最后，轉碼和組合物可在理論上導致對應用程序的用戶界面的彈性較小（盡管有此問題的解決方法）。

Router解決方案

Router（或中繼）的辦法使得H.264 SVC基礎設施普及，這也正是廣泛應用的。該架構基于具有中心點從每個發送器接收一個流并發送出一個流到每一個參與者。這個中心點只做數據包檢測和轉發，而不是昂貴的編碼和實際的媒體的解碼。常見術語是SFU。

?

Router解決方案

Router提供一個便宜的可擴展的多方傳輸，具有較好的延遲性、與傳統的mixer解決方案相比沒有質量劣化。

這種方案非常適合大并發的事實會議和直播。目前較成熟的服務提供商就是聲網

來一張各個解決方案的流量圖？

我應該使用哪種架構？

這個就需要根據自己的項目的需要了。其實，商業解決方案，包括上述所有方案，往往需要根據客戶的實際應用場景選擇對于的方法。不過，也有經驗，你可以使用一些通用規則。

1、如果您僅是提供P2P音視頻傳輸的服務，Mesh架構可能是最適合你的。另外，如果基礎設施的成本不是問題，并且參與者具有異構連接，這可以是一個很好的解決方案。

2、假設你提供企業級服務，且有較好的寬帶和高效的硬件（即一個企業內部服務），參加人數是有限的，那么你非常適合Mixer方案。

3、一般來說，如果你提供大規模服務的，應優先考慮到Router的方法。Router傳輸接近把情報在網絡的邊界，構建最終用戶應用程序時，以達到更好的可擴展性和靈活性的網絡的范例。

總結

以上是生活随笔為你收集整理的基于webrtc多人音视频的研究（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。