作者：Tsahi Levent-Levi（原文連結） 翻譯：劉通 原標題：Do I Need a Media Server for a One-to-Many WebRTC Broadcast? 譯文刊載於WebRTC.org.cn，歡迎入群討論：659922087
一個字回答：要。
這是我這個星期經常被問到的問題。答案也很簡單—是的，需要。
接著我收到了一個沒有預料到的提問：
為什麼需要？
這有點讓我措手不及。倒不是因為我不知道答案。而是因為我不知道如何用簡短的文字來回答他。我想這也不是一個簡單的問題。
簡單的答案是資源的限制，以及我們不控制大部分這些資源的事實。
硬性上限
無論何時我們想要將兩個瀏覽器使用流直接連線，都需要建立並使用對等連線。
Chrome 65版本包含了用於垃圾收集目的的上限。Chrome不允許超過500個併發對等連線同時存在。
500是一個非常大的數字了。如果你準備使用多餘10個的併發對等連線，那麼你應該是知道自己在做什麼的人之一（並且不需要本篇文章的幫助）。對於所有我能記得參與過的用例來說，超過50的基本上都是一個壞主意。
你需要認清楚資源是有限的。免費並在瀏覽器中實施並不意味著不會產生任何相關費用，或者不需要在實現過程中出人出力。
位元率，速度以及反饋
這應該是你無法使用WebRTC或者任何其他技術進行廣播的主要原因了。
我們正在觸碰的是WebRTC中充滿挑戰的部分。媒體處理很難。而實時媒體處理更難。
假設我們想以低VGA解析度廣播一個視訊。我們已經檢查並確定了500kbps的位元率可以滿足我們的需求。
如果我們向10個人播放我們的資料流，會發生什麼？
將我們的資料流廣播到10個人，需要5Mbps的上行鏈路位元率。
如果我們使用的是ADSL連線，那麼我們只有1-3Mbps的上行鏈路，所以我們將無法向我們的10個觀眾廣播該流。
大部分情況下，我們無法控制廣播者的目標。是通過ADSL？還是無線WiFi？還是連線不暢的3G網路？當我們開始處理廣播時，我們需要做出這些假設。
這是關於10個觀眾的。那如果我們要面對的是100個觀眾？1000個？或者100萬個？
使用媒體伺服器，我們要決定網路的連線性，伺服器的機器型別等等。我們可以決定把媒體伺服器級聯起來以擴大我們的廣播規模。我們對這種情況會有更多的控制。
所以廣播WebRTC媒體流需要媒體伺服器。
傳送端一致性
這點在網格狀群組通話中很常見，但是在廣播中也同樣重要。
當我們將WebRTC用於廣播型別的服務時，很多決定最終都會發生在媒體伺服器中。如果觀眾所處的網路環境不好，則會導致丟包，報告給媒體伺服器。那麼媒體伺服器在這種情況下會做什麼呢？
雖然沒有一個簡單的答案來回答這個問題，但是其中包括了這些選項：
-
要求廣播者傳送一個新的I-幀，這會影響所有的觀眾，並在不就的將來增加頻寬使用。
-
要求廣播者降低位元率和媒體質量以適應丟包，這不僅僅會影響不良網路上的觀眾，也會影響到所有收看者
-
忽略丟包的問題，犧牲部分觀眾給其他人提供“更好”的服務
-
使用同播或SVC，並將觀眾轉移到較低媒體質量的較低“層”，而不會影響其他使用者。
你不能在瀏覽器中完成大部分操作。瀏覽器傾向於使用相同的單一編碼流傳送給所有其他使用者，並且在多使用者方面正確估計頻寬做得不好。這不是設計成或者實施成這樣的。
你需要一個媒體伺服器
在大多數情況下，某些時候你需要一個媒體伺服器。
如果你正在廣播，那麼媒體伺服器是強制性的。谷歌不提供這樣的美俄費服務，甚至不提供針對該用例的開原始碼。
這不意味著媒體伺服器不能擁有—只是需要你更加努力。