單個(gè)群組WebRTC視頻通話中可以容納多少用戶

時(shí)間：2018-10-15 14:10:01

關(guān)鍵字： webrtc 視頻通信

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]只要你想，在WebRTC視頻通話中添加從一到一百萬的用戶都是可以的。當(dāng)被要求創(chuàng)建一個(gè)群組視頻通話時(shí)，顯然，針對(duì)該項(xiàng)目應(yīng)該選擇WebRTC技術(shù)。這幾乎是唯一的選擇，而且肯定也是性價(jià)比最好的。這時(shí)有個(gè)很大

只要你想，在WebRTC視頻通話中添加從一到一百萬的用戶都是可以的。

當(dāng)被要求創(chuàng)建一個(gè)群組視頻通話時(shí)，顯然，針對(duì)該項(xiàng)目應(yīng)該選擇WebRTC技術(shù)。這幾乎是唯一的選擇，而且肯定也是性價(jià)比最好的。這時(shí)有個(gè)很大的問題：?jiǎn)蝹€(gè)群組WebRTC視頻通話中可以容納多少用戶？

每周至少有一次我會(huì)被問到：WebRTC是點(diǎn)對(duì)點(diǎn)的，能否用于大型群組通話，因?yàn)檫@種技術(shù)可能不適合這種用例。事實(shí)上，WebRTC技術(shù)十分適合大型群組通話。

您需要做的是，將WebRTC看作一組技術(shù)構(gòu)建模塊，根據(jù)具體需求進(jìn)行整合和匹配，同時(shí)，WebRTC在瀏覽器中的實(shí)現(xiàn)也只是其中一個(gè)構(gòu)建模塊。

目前，WebRTC技術(shù)中支持群組視頻通話的最常用構(gòu)件是SFU（選擇性轉(zhuǎn)發(fā)單元），這是一個(gè)媒體路由器，它接收所有來自會(huì)話的參與者的媒體流，并決定傳輸路徑。

在本文中，我想要討論的是，在創(chuàng)建支持使用WebRTC的大型視頻會(huì)話的應(yīng)用程序時(shí)，需要考慮的幾個(gè)方面和決策。

分析復(fù)雜性

首先，來分析一下我們用例的復(fù)雜性。

對(duì)于WebRTC，以及實(shí)時(shí)視頻通信，我們將歸結(jié)為速度和流數(shù):

1、速度——在服務(wù)器中我們所期待的分辨率和比特率。

2、流數(shù)——單個(gè)會(huì)話的媒體流數(shù)量。

讓我們從一個(gè)例子開始。

假設(shè)你為企業(yè)提供一個(gè)群組通話服務(wù)。它可以在全球范圍內(nèi)運(yùn)行。人們將一起參加工作會(huì)議。你計(jì)劃將小組會(huì)議限制在4人以內(nèi)。我知道你想要更多參與者，但在這個(gè)例子中我只是想讓事情變得簡(jiǎn)單明了。

上面的插圖顯示了4人參與會(huì)議的示意圖，4個(gè)人多對(duì)多的推流和拉流就形成了魔方矩陣方式的推拉流關(guān)系（布局）。

魔方矩陣方式：720p

如果你希望這個(gè)視頻會(huì)議是魔方矩陣式的布局，我們的討論如下:

你想要高質(zhì)量的視頻。這就是每個(gè)人都想要的。因此，針對(duì)WQHD顯示器（即2560×1440），你計(jì)劃讓所有參與者發(fā)送分辨率為720p的視頻。它消耗了1.5Mbps(這里我很吝嗇，它可能需要更多)，所以:

會(huì)話中的每個(gè)參與者發(fā)送1.5Mbps，接收3個(gè)1.5Mbps的流

在4個(gè)參與者中，媒體服務(wù)器需要接收6Mbps并發(fā)送18Mbps的數(shù)據(jù)。

總結(jié)在一張簡(jiǎn)單的表格中，我們得到：

魔方矩陣方式：VGA

如果您對(duì)分辨率不太感興趣，可以針對(duì)VGA分辨率，甚至將比特率限制600Kbps：

以VGA標(biāo)準(zhǔn)傳輸視頻時(shí)，需要避免的事情是在顯示器上提高分辨率 - 因?yàn)榭雌饋頃?huì)很難看，特別是在較大的4K顯示器上。

即使在餐巾紙上粗略地計(jì)算，可以得出，一個(gè)分辨率為720P的視頻會(huì)議消耗的帶寬大概相當(dāng)于3個(gè)VGA會(huì)議。

Hangouts方式

但是如果我們的布局有點(diǎn)不同呢？像圖示有主要演講者和以較小窗口出現(xiàn)的其他參與者：

我稱之為Hangouts方式，因?yàn)镠angouts以這種布局而聞名，并且屬于第一批專門使用這種方式而不提供更多額外的布局。

這一次，我們將使用聯(lián)播的方式（simulcast），并計(jì)劃讓每個(gè)人都發(fā)送高質(zhì)量的視頻，SFU決定使用哪個(gè)輸入流作為主要的發(fā)言人并為其選擇更高的分辨率，而其他參會(huì)者則選擇較低的分辨率。

經(jīng)過幾次實(shí)驗(yàn)后，發(fā)現(xiàn)將較低分辨率的視頻縮放到較大顯示器時(shí)看起來不太好，所以你決定選取720p。你最終得到如下結(jié)果：

.會(huì)話中的每個(gè)參與者發(fā)送2.2Mbps（對(duì)于720p的視頻流，這是1.5Mbps，對(duì)于其他聯(lián)播的參與者會(huì)有額外80Kbps）

.會(huì)話中的每個(gè)參與者從占主導(dǎo)地位的發(fā)言者接收到1.5Mbps的數(shù)據(jù)，同時(shí)還有來自于較小窗口的兩個(gè)~300Mbps的輸入數(shù)據(jù)流

.在4名參與者中，媒體服務(wù)器需要接收8.8Mbps并發(fā)送8.4Mbps的視頻流

這里我們可以學(xué)到：

不同的用例中，具有相同用戶數(shù)量的群組視頻，在媒體服務(wù)器上會(huì)轉(zhuǎn)換為不同的負(fù)載。

如果沒有特別提到，聯(lián)播（simulcast）的效果是最好的，它提高了群組呼叫的效率和質(zhì)量（聯(lián)播是我們?cè)贖angouts方式的視頻會(huì)議中使用的）。

在我們描述的用于4路視頻通話的3種場(chǎng)景中，我們得到了在SFU上3組的不同數(shù)據(jù)：

在WebRTC呼叫中有多少用戶處于活躍狀態(tài)？

這是個(gè)棘手的問題。

如果你使用的是MCU，在MCU可以處理的前提下，呼叫數(shù)量可以盡可能多。

如果您使用的是SFU，則取決于3個(gè)不同的參數(shù)：

1. 媒體服務(wù)器的復(fù)雜程度以及它的性能

2. 在客戶端設(shè)備上可用的資源

3. 構(gòu)建基礎(chǔ)架構(gòu)和實(shí)現(xiàn)級(jí)聯(lián)的方式

我們很快會(huì)回顧這些。

同樣的場(chǎng)景，不同的實(shí)現(xiàn)

在單次呼叫中，當(dāng)用戶達(dá)到8-10個(gè)時(shí)，情況會(huì)變得復(fù)雜。這里我想分享一個(gè)公共服務(wù)（產(chǎn)品）的例子。

場(chǎng)景如下：

.在魔方矩陣方式布局中單次會(huì)議有9名參與者

.使用testRTC進(jìn)入會(huì)話，實(shí)現(xiàn)全自動(dòng)化

.因?yàn)槭莇emo，在運(yùn)行一分鐘之后進(jìn)程會(huì)自動(dòng)結(jié)束

.考慮到屏幕上有9個(gè)人，所以將所有人的分辨率降低到VGA，并分配1.3Mbps

.導(dǎo)致瀏覽器將接收10Mbps的數(shù)據(jù)進(jìn)行處理

在這里媒體服務(wù)器會(huì)決定如何限制和測(cè)量流量。

這里是另一個(gè)demo，進(jìn)行的是完全相同場(chǎng)景：

現(xiàn)在每個(gè)瀏覽器的平均傳入速率僅為2.7Mbps，幾乎是其他服務(wù)的四分之一。

同樣的場(chǎng)景，不同的實(shí)現(xiàn)。

對(duì)于主流應(yīng)用產(chǎn)品又如何？

基于SFU模型的視頻會(huì)議，市面上的一些主流應(yīng)用產(chǎn)品又如何？他們的應(yīng)用程序中關(guān)于參會(huì)者規(guī)模有什么樣的限制？

以下是我從網(wǎng)上搜集到的內(nèi)容：

.Google Hangouts - 一次會(huì)議中最多有25位參與者，過去是最多容納10個(gè)人。當(dāng)我第一次也是唯一一次使用它進(jìn)行WebRTC培訓(xùn)時(shí)，參會(huì)者人數(shù)一超過10人就卡死了，導(dǎo)致了我只能選擇使用其他視頻會(huì)議服務(wù)。

.Hangouts Meet - 在單個(gè)會(huì)話中將其參與者人數(shù)限制在50人以內(nèi)

.Houseparty - 8名參與者

.Skype - 25名參與者

.appear.in - 使用專業(yè)帳戶登錄，單個(gè)房間內(nèi)最多支持12個(gè)參與者

.Amazon Chime - 桌面版16位參與者，iOS上最多8位參與者（尚未支持安卓）

.Atlassian Stride and Meet Jitsi - 50位參與者

這是否意味著不能超過50個(gè)參與者？

我認(rèn)為隨著會(huì)議規(guī)模的增加，難度越來越大：

CPaas對(duì)尺寸的限制

當(dāng)您查看CPaaS平臺(tái)時(shí)，那些支持視頻和群組呼叫的服務(wù)通常會(huì)限制其會(huì)議規(guī)模。在大多數(shù)情況下，他們會(huì)給出一個(gè)他們測(cè)試過的或適合的參會(huì)者人數(shù)。正如我們所看到的那樣，這個(gè)參會(huì)者人數(shù)適用于一個(gè)非常具體的場(chǎng)景，但很可能不是你要滿足的場(chǎng)景需求。

在CPaaS中，在單個(gè)會(huì)話中，這些數(shù)字在從10位到100位參與者不等。通常情況下，如果超過給定的參會(huì)者人數(shù)，則超過指定數(shù)目的參與者只能觀看而不能發(fā)言。

要記住的關(guān)鍵點(diǎn)

需要記住的幾件事：

.群組規(guī)模越大，實(shí)施和優(yōu)化的復(fù)雜性就越高

.瀏覽器需要運(yùn)行多個(gè)解碼器，這本身就是一種負(fù)擔(dān)

.在這種情況下，移動(dòng)設(shè)備，特別是舊設(shè)備，可能很快就會(huì)癱倒。在確定要支持的會(huì)議人數(shù)規(guī)模之前，測(cè)試你計(jì)劃支持中的最老式，最小型的設(shè)備

.您可以構(gòu)建SFU，使其不會(huì)將所有傳入的媒體流路由到每個(gè)人，而是選擇部分?jǐn)?shù)據(jù)發(fā)送出去。例如，音頻通道上只傳送一個(gè)發(fā)言人的音頻數(shù)據(jù)，或者4個(gè)最重要的發(fā)言人的音頻數(shù)據(jù)

調(diào)整您的媒體服務(wù)器

調(diào)整大小和媒體服務(wù)器是我最近在testRTC上做的事情。過去我們?cè)?jīng)和Kurento合作過一段時(shí)間，并正在計(jì)劃修補(bǔ)其他媒體服務(wù)器。我參與的每個(gè)項(xiàng)目中都會(huì)遇到這個(gè)問題：

在單個(gè)媒體服務(wù)器中，我們最多可以添加多少會(huì)話/用戶/流？

根據(jù)我們上面看到的關(guān)于速度和流數(shù)的內(nèi)容，最穩(wěn)妥的回答應(yīng)該是：這很大程度上取決于你在實(shí)現(xiàn)什么業(yè)務(wù)。

如果你需要的是每個(gè)人都處于活躍狀態(tài)的群組呼叫，你應(yīng)該選取在一臺(tái)服務(wù)器上容納100-500名參與者的方案。這些數(shù)字會(huì)根據(jù)你為媒體服務(wù)器選擇的計(jì)算機(jī)以及每個(gè)數(shù)據(jù)流平均計(jì)劃的比特率而有所不同。

如果你需要的是一個(gè)單主播對(duì)多觀眾的聯(lián)播，使用WebRTC是為了維持低延遲，200-1,000是較理想的估計(jì)規(guī)模，甚至可能更多。

大型機(jī)器還是小型機(jī)器？

你需要解決的另一件事是，要選擇哪臺(tái)計(jì)算機(jī)來托管你的媒體服務(wù)器。是選擇性能較差的大機(jī)器，還是體驗(yàn)良好的小機(jī)器呢？

使用大型機(jī)器意味著你可以在一個(gè)服務(wù)器中添加更多的觀眾，這樣服務(wù)的復(fù)雜性就會(huì)降低。但是如果發(fā)生崩潰（媒體服務(wù)器崩潰），就會(huì)有更多的用戶受到影響。當(dāng)你需要升級(jí)你的媒體服務(wù)器（很顯然你會(huì)），這個(gè)過程會(huì)讓你付出更多的代價(jià)，或者變得更加復(fù)雜。

機(jī)器越大，它的內(nèi)核就越多。這導(dǎo)致需要在多線程模式下運(yùn)行媒體服務(wù)器。這意味著它們構(gòu)建、調(diào)試和修復(fù)變得更加復(fù)雜。也增加更多不確定的部分。

選擇小型機(jī)器意味著你會(huì)更早地遇到規(guī)模問題，他們將需要更精細(xì)的算法和啟發(fā)式算法。在負(fù)載平衡服務(wù)時(shí)，會(huì)出現(xiàn)更多的極端情況。

基于流，帶寬還是CPU來確定規(guī)模？

如何確定你的媒體服務(wù)器達(dá)到了滿負(fù)載？如何決定下一個(gè)會(huì)話是否需要一臺(tái)新機(jī)器，還是放置在當(dāng)前使用的媒體服務(wù)器上？如果選擇當(dāng)前使用的媒體服務(wù)器，當(dāng)新的參與者想要加入在此媒體服務(wù)器上正在運(yùn)行的會(huì)話時(shí)，那么他們是否有足夠的空間？

這些問題不容易回答。

通常有3種不同的度量標(biāo)準(zhǔn)，用于決定何時(shí)從單個(gè)媒體服務(wù)器擴(kuò)展到其他服務(wù)器。具體如下：

基于CPU?- 當(dāng)CPU達(dá)到一定的百分比時(shí)，意味著機(jī)器是“滿”的。當(dāng)你使用較小的機(jī)器時(shí)，它的效果最好，因?yàn)镃PU是你消耗的第一個(gè)資源。

基于帶寬?- SFU消耗了大量網(wǎng)絡(luò)資源。如果你使用的是更大的機(jī)器，你可能不會(huì)達(dá)到CPU的極限，但是最終會(huì)消耗太多的帶寬。所以最終將通過帶寬監(jiān)控來決定可用的容量。

基于數(shù)據(jù)流?- 有時(shí)基于CPU和帶寬的挑戰(zhàn)在于，根據(jù)動(dòng)態(tài)條件，可支持的會(huì)話和數(shù)據(jù)流的數(shù)量可能會(huì)有所不同。通過策略調(diào)整可能也無法應(yīng)對(duì)這種情況，所以可能需要更多的計(jì)算。這將導(dǎo)致無論是基于CPU還是帶寬來調(diào)整計(jì)算機(jī)的大小，都需要根據(jù)服務(wù)器可支持的數(shù)據(jù)流數(shù)量制定規(guī)則。

這里面臨的挑戰(zhàn)是，無論你選擇哪種方案，確定規(guī)模都是需要獨(dú)自完成的。我看到，在需要解決這個(gè)問題時(shí)，很多人會(huì)選擇使用testRTC。

級(jí)聯(lián)單個(gè)會(huì)話

級(jí)聯(lián)是將一個(gè)媒體服務(wù)器連接到另一個(gè)媒體服務(wù)器的過程。如圖所示：

我們有一個(gè)4路組視頻電話，分布在3個(gè)不同的媒體服務(wù)器上。服務(wù)器根據(jù)需要在它們之間建立連接。為什么要做這個(gè)？

＃1 - 地理分布

當(dāng)將SFU作為其中一部分并在全球范圍中提供服務(wù)時(shí)，立即引發(fā)的問題是在進(jìn)行新的會(huì)話時(shí)，您將為其分配哪個(gè)SFU？在哪些數(shù)據(jù)中心？由于我們希望讓媒體服務(wù)器盡可能靠近用戶，因此我們要么提前知道有關(guān)會(huì)話的信息并根據(jù)這決定將其分配到哪里，要么通過合理的方式來決定，比如地理定位 - 我們選擇在離用戶最近的數(shù)據(jù)中心創(chuàng)建會(huì)議。

假設(shè)4人正在通話。其中3人來自紐約，而第4個(gè)人來自法國。但是如果是這個(gè)法國人最先加入到這個(gè)通話中，那么會(huì)發(fā)生什么？

結(jié)果是該服務(wù)器將會(huì)在法國托管。4人中有3人將遠(yuǎn)離媒體服務(wù)器。顯然這不是最好的方法...

一種解決方案是，通過距離參與者最近的服務(wù)器之間進(jìn)行傳播的方式來進(jìn)行會(huì)議：

我們使用更多的服務(wù)器資源來獲取此會(huì)話，但我們對(duì)媒體路由有更多的控制權(quán)，所以我們可以更好地優(yōu)化它們。這提高了會(huì)議的媒體質(zhì)量。

＃2 - 碎片分配

假設(shè)我們可以在單個(gè)媒體服務(wù)器上連接多達(dá)100個(gè)參與者。此外，每次會(huì)議最多可容納10人。理想情況下，我們不希望為每個(gè)媒體服務(wù)器分配超過10次會(huì)議。

但是如果我告訴你會(huì)議的平均規(guī)模是2人呢？那么我們將得到這樣的分配:

這會(huì)導(dǎo)致服務(wù)器資源的大量浪費(fèi)。我們?cè)撊绾谓鉀Q這個(gè)問題？

1. 通過預(yù)設(shè)人數(shù)達(dá)到最大會(huì)議規(guī)模。但這不是真正需要做的事情

2. 冒一個(gè)風(fēng)險(xiǎn)，假設(shè)你分配了50%的服務(wù)器容量，那么剩余的容量則是留給現(xiàn)有的會(huì)議以應(yīng)對(duì)參會(huì)人數(shù)的增長(zhǎng)。雖然仍然是在浪費(fèi)資源，但程度較低。由于服務(wù)器資源的限制，我們可能無法應(yīng)對(duì)會(huì)議中可能出現(xiàn)的邊緣情況

3. 通過跨媒體服務(wù)器遷移會(huì)話對(duì)服務(wù)器進(jìn)行“碎片整理”。這聽起來不太有友好，而且可能會(huì)擾亂用戶。

4. 級(jí)聯(lián)會(huì)話。允許跨機(jī)器的規(guī)模增長(zhǎng)

最后一個(gè)級(jí)聯(lián)中，您可以通過預(yù)留部分媒體服務(wù)器的資源，來實(shí)現(xiàn)將現(xiàn)有會(huì)話級(jí)聯(lián)到其他媒體服務(wù)器的目的。

＃3 - 更大的會(huì)議

假設(shè)您想創(chuàng)建比單個(gè)媒體服務(wù)器能夠處理的更大型會(huì)議，那么唯一的選擇就是級(jí)聯(lián)。

如果您的媒體服務(wù)器可以容納100名參與者，但是您希望參加規(guī)模為5000名的會(huì)議，那么您需要通過級(jí)聯(lián)以支持他們。但這并不容易，這就解釋了為什么沒有很多這樣的解決方案可以用，但這是可能實(shí)現(xiàn)的。

請(qǐng)注意，在這樣的大型會(huì)議上，媒體流不會(huì)是雙向的。在會(huì)議中，發(fā)送媒體流的參與者比較少，絕大部分的參與者都只是接收媒體流。關(guān)于純粹的聯(lián)播場(chǎng)景，在Red5 Pro博客上我寫了一篇關(guān)于的縮放挑戰(zhàn)的文章。

概括

本文中我們觸及了很多領(lǐng)域。在嘗試確定在WebRTC視頻通話中能夠有多少用戶時(shí)，應(yīng)該做的是：

1. 無論會(huì)議是什么規(guī)模，都能使用WebRTC支持實(shí)現(xiàn)

1.1. 這是一個(gè)成本問題，并與商業(yè)模式保持一致，這將決定或打破這一模式。

1.2. 會(huì)議規(guī)模越大，實(shí)現(xiàn)的方式就會(huì)越復(fù)雜，同時(shí)需要更多的限制和假設(shè)

2. 分析你需要支持的復(fù)雜性

2.1. 統(tǒng)計(jì)每個(gè)設(shè)備和媒體服務(wù)器的傳入和傳出流

2.2. 決定每個(gè)流的視頻質(zhì)量（分辨率和比特率）

3. 定義將使用的媒體服務(wù)器

3.1. 選擇一種機(jī)器類型以運(yùn)行媒體服務(wù)器

3.2. 在擴(kuò)展之前計(jì)算出所需的規(guī)模

3.3. 檢查服務(wù)器資源上的增長(zhǎng)是否是線性的