只要你想,在WebRTC視頻通話中添加從一到一百萬的用戶都是可以的。
當被要求創(chuàng)建一個群組視頻通話時,顯然,針對該項目應該選擇WebRTC技術。這幾乎是唯一的選擇,而且肯定也是性價比最好的。這時有個很大的問題:單個群組WebRTC視頻通話中可以容納多少用戶?
每周至少有一次我會被問到:WebRTC是點對點的,能否用于大型群組通話,因為這種技術可能不適合這種用例。事實上,WebRTC技術十分適合大型群組通話。
您需要做的是,將WebRTC看作一組技術構建模塊,根據(jù)具體需求進行整合和匹配,同時,WebRTC在瀏覽器中的實現(xiàn)也只是其中一個構建模塊。
目前,WebRTC技術中支持群組視頻通話的最常用構件是SFU(選擇性轉(zhuǎn)發(fā)單元),這是一個媒體路由器,它接收所有來自會話的參與者的媒體流,并決定傳輸路徑。
在本文中,我想要討論的是,在創(chuàng)建支持使用WebRTC的大型視頻會話的應用程序時,需要考慮的幾個方面和決策。
分析復雜性
首先,來分析一下我們用例的復雜性。
對于WebRTC,以及實時視頻通信,我們將歸結為速度和流數(shù):
1、速度——在服務器中我們所期待的分辨率和比特率。
2、流數(shù)——單個會話的媒體流數(shù)量。
讓我們從一個例子開始。
假設你為企業(yè)提供一個群組通話服務。它可以在全球范圍內(nèi)運行。人們將一起參加工作會議。你計劃將小組會議限制在4人以內(nèi)。我知道你想要更多參與者,但在這個例子中我只是想讓事情變得簡單明了。
上面的插圖顯示了4人參與會議的示意圖,4個人多對多的推流和拉流就形成了魔方矩陣方式的推拉流關系(布局)。
魔方矩陣方式:720p
如果你希望這個視頻會議是魔方矩陣式的布局,我們的討論如下:
你想要高質(zhì)量的視頻。這就是每個人都想要的。因此,針對WQHD顯示器(即2560×1440),你計劃讓所有參與者發(fā)送分辨率為720p的視頻。它消耗了1.5Mbps(這里我很吝嗇,它可能需要更多),所以:
會話中的每個參與者發(fā)送1.5Mbps,接收3個1.5Mbps的流
在4個參與者中,媒體服務器需要接收6Mbps并發(fā)送18Mbps的數(shù)據(jù)。
總結在一張簡單的表格中,我們得到:
魔方矩陣方式:VGA
如果您對分辨率不太感興趣,可以針對VGA分辨率,甚至將比特率限制600Kbps:
以VGA標準傳輸視頻時,需要避免的事情是在顯示器上提高分辨率 - 因為看起來會很難看,特別是在較大的4K顯示器上。
即使在餐巾紙上粗略地計算,可以得出,一個分辨率為720P的視頻會議消耗的帶寬大概相當于3個VGA會議。
Hangouts方式
但是如果我們的布局有點不同呢?像圖示有主要演講者和以較小窗口出現(xiàn)的其他參與者:
我稱之為Hangouts方式,因為Hangouts以這種布局而聞名,并且屬于第一批專門使用這種方式而不提供更多額外的布局。
這一次,我們將使用聯(lián)播的方式(simulcast),并計劃讓每個人都發(fā)送高質(zhì)量的視頻,SFU決定使用哪個輸入流作為主要的發(fā)言人并為其選擇更高的分辨率,而其他參會者則選擇較低的分辨率。
經(jīng)過幾次實驗后,發(fā)現(xiàn)將較低分辨率的視頻縮放到較大顯示器時看起來不太好,所以你決定選取720p。你最終得到如下結果:
.會話中的每個參與者發(fā)送2.2Mbps(對于720p的視頻流,這是1.5Mbps,對于其他聯(lián)播的參與者會有額外80Kbps)
.會話中的每個參與者從占主導地位的發(fā)言者接收到1.5Mbps的數(shù)據(jù),同時還有來自于較小窗口的兩個~300Mbps的輸入數(shù)據(jù)流
.在4名參與者中,媒體服務器需要接收8.8Mbps并發(fā)送8.4Mbps的視頻流
這里我們可以學到:
不同的用例中,具有相同用戶數(shù)量的群組視頻,在媒體服務器上會轉(zhuǎn)換為不同的負載。
如果沒有特別提到,聯(lián)播(simulcast)的效果是最好的,它提高了群組呼叫的效率和質(zhì)量(聯(lián)播是我們在Hangouts方式的視頻會議中使用的)。
在我們描述的用于4路視頻通話的3種場景中,我們得到了在SFU上3組的不同數(shù)據(jù):
在WebRTC呼叫中有多少用戶處于活躍狀態(tài)?
這是個棘手的問題。
如果你使用的是MCU,在MCU可以處理的前提下,呼叫數(shù)量可以盡可能多。
如果您使用的是SFU,則取決于3個不同的參數(shù):
1. 媒體服務器的復雜程度以及它的性能
2. 在客戶端設備上可用的資源
3. 構建基礎架構和實現(xiàn)級聯(lián)的方式
我們很快會回顧這些。
同樣的場景,不同的實現(xiàn)
在單次呼叫中,當用戶達到8-10個時,情況會變得復雜。這里我想分享一個公共服務(產(chǎn)品)的例子。
場景如下:
.在魔方矩陣方式布局中單次會議有9名參與者
.使用testRTC進入會話,實現(xiàn)全自動化
.因為是demo,在運行一分鐘之后進程會自動結束
.考慮到屏幕上有9個人,所以將所有人的分辨率降低到VGA,并分配1.3Mbps
.導致瀏覽器將接收10Mbps的數(shù)據(jù)進行處理
在這里媒體服務器會決定如何限制和測量流量。
這里是另一個demo,進行的是完全相同場景:
現(xiàn)在每個瀏覽器的平均傳入速率僅為2.7Mbps,幾乎是其他服務的四分之一。
同樣的場景,不同的實現(xiàn)。
對于主流應用產(chǎn)品又如何?
基于SFU模型的視頻會議,市面上的一些主流應用產(chǎn)品又如何?他們的應用程序中關于參會者規(guī)模有什么樣的限制?
以下是我從網(wǎng)上搜集到的內(nèi)容:
.Google Hangouts - 一次會議中最多有25位參與者,過去是最多容納10個人。當我第一次也是唯一一次使用它進行WebRTC培訓時,參會者人數(shù)一超過10人就卡死了,導致了我只能選擇使用其他視頻會議服務。
.Hangouts Meet - 在單個會話中將其參與者人數(shù)限制在50人以內(nèi)
.Houseparty - 8名參與者
.Skype - 25名參與者
.appear.in - 使用專業(yè)帳戶登錄,單個房間內(nèi)最多支持12個參與者
.Amazon Chime - 桌面版16位參與者,iOS上最多8位參與者(尚未支持安卓)
.Atlassian Stride and Meet Jitsi - 50位參與者
這是否意味著不能超過50個參與者?
我認為隨著會議規(guī)模的增加,難度越來越大:
CPaas對尺寸的限制
當您查看CPaaS平臺時,那些支持視頻和群組呼叫的服務通常會限制其會議規(guī)模。在大多數(shù)情況下,他們會給出一個他們測試過的或適合的參會者人數(shù)。正如我們所看到的那樣,這個參會者人數(shù)適用于一個非常具體的場景,但很可能不是你要滿足的場景需求。
在CPaaS中,在單個會話中,這些數(shù)字在從10位到100位參與者不等。通常情況下,如果超過給定的參會者人數(shù),則超過指定數(shù)目的參與者只能觀看而不能發(fā)言。
要記住的關鍵點
需要記住的幾件事:
.群組規(guī)模越大,實施和優(yōu)化的復雜性就越高
.瀏覽器需要運行多個解碼器,這本身就是一種負擔
.在這種情況下,移動設備,特別是舊設備,可能很快就會癱倒。在確定要支持的會議人數(shù)規(guī)模之前,測試你計劃支持中的最老式,最小型的設備
.您可以構建SFU,使其不會將所有傳入的媒體流路由到每個人,而是選擇部分數(shù)據(jù)發(fā)送出去。例如,音頻通道上只傳送一個發(fā)言人的音頻數(shù)據(jù),或者4個最重要的發(fā)言人的音頻數(shù)據(jù)
調(diào)整您的媒體服務器
調(diào)整大小和媒體服務器是我最近在testRTC上做的事情。過去我們曾經(jīng)和Kurento合作過一段時間,并正在計劃修補其他媒體服務器。我參與的每個項目中都會遇到這個問題:
在單個媒體服務器中,我們最多可以添加多少會話/用戶/流?
根據(jù)我們上面看到的關于速度和流數(shù)的內(nèi)容,最穩(wěn)妥的回答應該是:這很大程度上取決于你在實現(xiàn)什么業(yè)務。
如果你需要的是每個人都處于活躍狀態(tài)的群組呼叫,你應該選取在一臺服務器上容納100-500名參與者的方案。這些數(shù)字會根據(jù)你為媒體服務器選擇的計算機以及每個數(shù)據(jù)流平均計劃的比特率而有所不同。
如果你需要的是一個單主播對多觀眾的聯(lián)播,使用WebRTC是為了維持低延遲,200-1,000是較理想的估計規(guī)模,甚至可能更多。
大型機器還是小型機器?
你需要解決的另一件事是,要選擇哪臺計算機來托管你的媒體服務器。是選擇性能較差的大機器,還是體驗良好的小機器呢?
使用大型機器意味著你可以在一個服務器中添加更多的觀眾,這樣服務的復雜性就會降低。但是如果發(fā)生崩潰(媒體服務器崩潰),就會有更多的用戶受到影響。當你需要升級你的媒體服務器(很顯然你會),這個過程會讓你付出更多的代價,或者變得更加復雜。
機器越大,它的內(nèi)核就越多。這導致需要在多線程模式下運行媒體服務器。這意味著它們構建、調(diào)試和修復變得更加復雜。也增加更多不確定的部分。
選擇小型機器意味著你會更早地遇到規(guī)模問題,他們將需要更精細的算法和啟發(fā)式算法。在負載平衡服務時,會出現(xiàn)更多的極端情況。
基于流,帶寬還是CPU來確定規(guī)模?
如何確定你的媒體服務器達到了滿負載?如何決定下一個會話是否需要一臺新機器,還是放置在當前使用的媒體服務器上?如果選擇當前使用的媒體服務器,當新的參與者想要加入在此媒體服務器上正在運行的會話時,那么他們是否有足夠的空間?
這些問題不容易回答。
通常有3種不同的度量標準,用于決定何時從單個媒體服務器擴展到其他服務器。具體如下:
基于CPU?- 當CPU達到一定的百分比時,意味著機器是“滿”的。當你使用較小的機器時,它的效果最好,因為CPU是你消耗的第一個資源。
基于帶寬?- SFU消耗了大量網(wǎng)絡資源。如果你使用的是更大的機器,你可能不會達到CPU的極限,但是最終會消耗太多的帶寬。所以最終將通過帶寬監(jiān)控來決定可用的容量。
基于數(shù)據(jù)流?- 有時基于CPU和帶寬的挑戰(zhàn)在于,根據(jù)動態(tài)條件,可支持的會話和數(shù)據(jù)流的數(shù)量可能會有所不同。通過策略調(diào)整可能也無法應對這種情況,所以可能需要更多的計算。這將導致無論是基于CPU還是帶寬來調(diào)整計算機的大小,都需要根據(jù)服務器可支持的數(shù)據(jù)流數(shù)量制定規(guī)則。
這里面臨的挑戰(zhàn)是,無論你選擇哪種方案,確定規(guī)模都是需要獨自完成的。我看到,在需要解決這個問題時,很多人會選擇使用testRTC。
級聯(lián)單個會話
級聯(lián)是將一個媒體服務器連接到另一個媒體服務器的過程。如圖所示:
我們有一個4路組視頻電話,分布在3個不同的媒體服務器上。服務器根據(jù)需要在它們之間建立連接。為什么要做這個?
#1 - 地理分布
當將SFU作為其中一部分并在全球范圍中提供服務時,立即引發(fā)的問題是在進行新的會話時,您將為其分配哪個SFU?在哪些數(shù)據(jù)中心?由于我們希望讓媒體服務器盡可能靠近用戶,因此我們要么提前知道有關會話的信息并根據(jù)這決定將其分配到哪里,要么通過合理的方式來決定,比如地理定位 - 我們選擇在離用戶最近的數(shù)據(jù)中心創(chuàng)建會議。
假設4人正在通話。其中3人來自紐約,而第4個人來自法國。但是如果是這個法國人最先加入到這個通話中,那么會發(fā)生什么?
結果是該服務器將會在法國托管。4人中有3人將遠離媒體服務器。顯然這不是最好的方法...
一種解決方案是,通過距離參與者最近的服務器之間進行傳播的方式來進行會議:
我們使用更多的服務器資源來獲取此會話,但我們對媒體路由有更多的控制權,所以我們可以更好地優(yōu)化它們。這提高了會議的媒體質(zhì)量。
#2 - 碎片分配
假設我們可以在單個媒體服務器上連接多達100個參與者。此外,每次會議最多可容納10人。理想情況下,我們不希望為每個媒體服務器分配超過10次會議。
但是如果我告訴你會議的平均規(guī)模是2人呢?那么我們將得到這樣的分配:
這會導致服務器資源的大量浪費。我們該如何解決這個問題?
1. 通過預設人數(shù)達到最大會議規(guī)模。但這不是真正需要做的事情
2. 冒一個風險,假設你分配了50%的服務器容量,那么剩余的容量則是留給現(xiàn)有的會議以應對參會人數(shù)的增長。雖然仍然是在浪費資源,但程度較低。由于服務器資源的限制,我們可能無法應對會議中可能出現(xiàn)的邊緣情況
3. 通過跨媒體服務器遷移會話對服務器進行“碎片整理”。這聽起來不太有友好,而且可能會擾亂用戶。
4. 級聯(lián)會話。允許跨機器的規(guī)模增長
最后一個級聯(lián)中,您可以通過預留部分媒體服務器的資源,來實現(xiàn)將現(xiàn)有會話級聯(lián)到其他媒體服務器的目的。
#3 - 更大的會議
假設您想創(chuàng)建比單個媒體服務器能夠處理的更大型會議,那么唯一的選擇就是級聯(lián)。
如果您的媒體服務器可以容納100名參與者,但是您希望參加規(guī)模為5000名的會議,那么您需要通過級聯(lián)以支持他們。但這并不容易,這就解釋了為什么沒有很多這樣的解決方案可以用,但這是可能實現(xiàn)的。
請注意,在這樣的大型會議上,媒體流不會是雙向的。在會議中,發(fā)送媒體流的參與者比較少,絕大部分的參與者都只是接收媒體流。關于純粹的聯(lián)播場景,在Red5 Pro博客上我寫了一篇關于的縮放挑戰(zhàn)的文章。
概括
本文中我們觸及了很多領域。在嘗試確定在WebRTC視頻通話中能夠有多少用戶時,應該做的是:
1. 無論會議是什么規(guī)模,都能使用WebRTC支持實現(xiàn)
1.1. 這是一個成本問題,并與商業(yè)模式保持一致,這將決定或打破這一模式。
1.2. 會議規(guī)模越大,實現(xiàn)的方式就會越復雜,同時需要更多的限制和假設
2. 分析你需要支持的復雜性
2.1. 統(tǒng)計每個設備和媒體服務器的傳入和傳出流
2.2. 決定每個流的視頻質(zhì)量(分辨率和比特率)
3. 定義將使用的媒體服務器
3.1. 選擇一種機器類型以運行媒體服務器
3.2. 在擴展之前計算出所需的規(guī)模
3.3. 檢查服務器資源上的增長是否是線性的
3.4. 決定是否基于帶寬,CPU,流數(shù)或其他進行擴展
4. 圖示的級聯(lián)該如何實現(xiàn)
<p style="border:0px;color:rgb(25,25,25);font-family:'PingFang