WebRTC可以實(shí)現(xiàn)很多的應(yīng)用場景，基于WebRTC的視頻會議是WebRTC應(yīng)用場景中比較重要的一個場景。在疫情期間，很多用戶使用視頻會議進(jìn)行各種溝通，包括公司業(yè)務(wù)會議溝通，教育機(jī)構(gòu)的在線課程等使用。在使用過程中，很多用戶和筆者自己也有不同的體驗(yàn)結(jié)果。用戶體驗(yàn)結(jié)果取決于視頻會議的性能，在性能表現(xiàn)中，很多因素對視頻會議的性能有制約作用。為了能夠了解這些制約因素，結(jié)合筆者最近部署使用情況，和一些研究人員的結(jié)果，筆者通過漫談的形式對這些制約要素做一個完整介紹，以方便WebRTC開發(fā)人員，部署人員針對WebRTC媒體服務(wù)器，特別是開源WebRTC媒體服務(wù)器以及測試等參數(shù)做分享介紹。

再次說明，筆者不會涉及具體的視頻會議平臺，所以只是進(jìn)行比較寬泛的討論。因?yàn)槟壳叭狈Ρ容^完整的非常專業(yè)的視頻會議的測試工具，我們只能借助于很多第三方技術(shù)人員的數(shù)據(jù)來說明關(guān)于視頻會議性能的瓶頸討論。

在本文章的討論中，筆者準(zhǔn)備從幾個不同的方面來介紹WebRTC 服務(wù)器端的性能處理的介紹，具體包括：服務(wù)器端MCU/SFU模式的性能處理，主要影響要素，視頻會議畫面布局影響，測試工具討論，級聯(lián)/分布式部署討論和測試架構(gòu)以及不同環(huán)境和角度的測試數(shù)據(jù)分享。

說明：

1）引用的論文和研究數(shù)據(jù)可能存在時間延后，讀者最好參考最新文章。

2）數(shù)據(jù)分享沒有過多介紹數(shù)據(jù)結(jié)果的具體測試背景，筆者最好進(jìn)一步閱讀論文原文。

3）引用數(shù)據(jù)都來自于互聯(lián)網(wǎng)資源。

視頻會議部署方式-MCU/SFU

在討論視頻會議的性能時，我們首先需要確定基本的媒體處理架構(gòu)。如果在沒有確定基本的技術(shù)架構(gòu)之前討論視頻會議的性能是沒有任何意義，也不存在任何的可比性。因此，在以下的測試數(shù)據(jù)討論中一定要注意這個前提條件。

SFU vs MCU

本圖片以及以下圖例均來自于互聯(lián)網(wǎng)資源

根據(jù)以上圖例，我們可以看出，無論用戶部署采用何種方式，這些方式本身都有自己的特色，用戶需要自己根據(jù)實(shí)際情況做決定，決定因素包括網(wǎng)絡(luò)帶寬費(fèi)用，CPU資源費(fèi)用和部署管理方式等都需要考慮。目前，市場上主流廠家基本上或者使用MCU方式，或者使用SFU方式。因此，在接下來的各種穩(wěn)定性的數(shù)據(jù)說明中可能會涉及這些關(guān)鍵數(shù)據(jù)，因?yàn)椴渴鸱绞降牟煌?，這些數(shù)據(jù)也完全不同。除了以上說明以外，另外補(bǔ)充的幾點(diǎn)是：

• MCU方式帶寬消耗/CPU消耗的成本是否可以支撐業(yè)務(wù)本身
• MCU管理是一個非常大的挑戰(zhàn)，一旦MCU服務(wù)器出現(xiàn)問題，會影響所有終端的穩(wěn)定性。SFU在這方面相對風(fēng)險比較小。
• SFU寄希望終端來處理，消耗終端帶寬和CPU比較多。終端需要一定的優(yōu)化策略來完成高負(fù)載。隨著終端性能越來越高，目前看效果比較好。
• 因?yàn)镸CU服務(wù)器承擔(dān)了更多的媒體管理能力，所以，相對來說，MCU容易提供業(yè)務(wù)處理，SFU需要結(jié)合其他方式進(jìn)行處理。

以上分析僅簡單介紹了三種部署方式的存在的優(yōu)缺點(diǎn)。當(dāng)然，很多研究人員針對這些部署方式有很多更加完善的深度討論，讀者可以結(jié)合自己的用戶場景做進(jìn)一步學(xué)習(xí)，這里不再花費(fèi)時間介紹。

主要影響要素

大家都知道，基于互聯(lián)網(wǎng)的產(chǎn)品或者應(yīng)用的性能受制于很多環(huán)境因素，這些因素制約其性能。同樣，基于WebRTC的視頻會議系統(tǒng)也因?yàn)楹芏嘁蛩氐闹萍s，其性能會受到這些因素的影響。首先，筆者和大家分享一些筆者閱讀的關(guān)于WebRTC性能測試的一些研究結(jié)果和其相關(guān)論文。Bart Jansen在他發(fā)表的論文中提到了時延，丟包, 帶寬，部署方式（Mesh/SFU），視頻編碼（VP8，VP9，H264），移動網(wǎng)絡(luò)，無線網(wǎng)絡(luò)環(huán)境來進(jìn)行綜合測試。另外一位研究人員Sajjad Taheri在他發(fā)表的論文中，通過具體WebRTC的創(chuàng)建和媒體性能進(jìn)行了分析評價：

連接測試評價參數(shù)

媒體處理性能評價參數(shù)

Boni García在其發(fā)表的論文中針對WebRTC的瀏覽器進(jìn)行了比較深入的測試。Boris Grozev在關(guān)于其SFU測試和MCU測試中的測試了圖像質(zhì)量，客戶端資源占用率，渲染Rendered Frame Rate，服務(wù)器端資源占用率，流媒體切換時延等做了非常深度的分析。Cristian Constantin Spoiala針對WebRTC在容器和虛擬機(jī)境中針對Kurento做了完整的測試。Vamis XHAgjika???針對WebRTC云部署（MCU/SFU）環(huán)境發(fā)表了一篇關(guān)于WebRTC服務(wù)器的負(fù)載和性能測試的模型。做了部署環(huán)境以上這些測試都是從不同角度使用各種模型和工具對WebRTC資源和性能做的充分的測試。針對我們討論關(guān)于WebRTC 視頻會議服務(wù)器的性能有非常完整的認(rèn)識。

本文章中僅討論關(guān)于WebRTC的使用場景和WebRTC會議中的一些編碼和參數(shù)。如果涉及到更底層的圖像處理的參數(shù)和編碼處理，視頻質(zhì)量會取決于更多的影響參數(shù)。視頻會議著名廠家思科對傳輸網(wǎng)絡(luò)中其視頻質(zhì)量的服務(wù)保障有基本的參數(shù)標(biāo)準(zhǔn)：

思科針對視頻會議和視頻媒體流推薦的質(zhì)量影響變量：

雖然以上研究人員從不同的角度和應(yīng)用場景針對WebRTC性能做了詳細(xì)分析，但是因?yàn)槲覀兪褂脠鼍安煌?，我們不可能完全針對這些環(huán)境做深入了解，我們只能針對比較接近自己的環(huán)境進(jìn)行研究。因?yàn)楫?dāng)前關(guān)于WebRTC視頻會議的應(yīng)用比較關(guān)心，因此，我們更多會討論視頻會議部署中關(guān)于服務(wù)器端資源，終端資源和視頻圖像質(zhì)量等進(jìn)行進(jìn)一步分析。其他測試手段和項(xiàng)目讀者可以查閱相關(guān)行業(yè)研究成果來學(xué)習(xí)。

畫面布局處理的影響

在前面的討論中，筆者介紹了很多研究人員針對WebRTC的性能進(jìn)行的各種測試。但是，在這些測試中，針對瀏覽器界面布局的設(shè)置和分辨率的討論相對比較少。事實(shí)上，這個因素也是影響視頻會議穩(wěn)定性的重要因素。因此，這里我們單獨(dú)加以具體討論。在視頻會議的測試討論中，一般會根據(jù)基本的三個參數(shù)，分辨率（resolution），比特率和會話人數(shù)來確定。當(dāng)然，如果針對視頻還有更多細(xì)節(jié)的其他特性，例如顏色清晰度，穩(wěn)定性，偽影，銳度，對比度，亮度等非常專業(yè)的特性，這些特性可能會應(yīng)用在WebRTC環(huán)境中的一些行業(yè)應(yīng)用中，應(yīng)用軟件通過攝像頭獲取更多分析數(shù)據(jù)，進(jìn)行實(shí)時分析。這里，我們僅討論一般情況下，視頻會議中分辨率，傳輸比特率和會會人數(shù)的測試討論。根據(jù)這三個數(shù)據(jù)，用戶在視頻會議的畫面布局將會決定服務(wù)器端和終端的處理能力。在視頻會議的場景中，我們一般也做不到大家都使用非常高的分辨率，或者使用其他高清終端（實(shí)際上每個人都想獲得高清效果），但是視頻會議還有其特殊性，一般來說，會議主持人和演講人具有相對比較大的權(quán)限，這些人的布局設(shè)計(jì)可以通過調(diào)整的方式來實(shí)現(xiàn)，這樣就可以優(yōu)化整個視頻會議的系統(tǒng)性能。假設(shè)，如果用戶WQHD顯示器的話，有四個會議用戶的話，使用SFU的模式處理方式的話，根據(jù)布局和分辨率的不同，SFU服務(wù)器所占用的發(fā)送和接收到帶寬都完全不同，用戶端的帶寬占用也完全不同。一些圖例對比了如果用戶使用720P，VGA和Hangouts模式的實(shí)際帶寬：

目前，比較熱門的一些視頻會議基本上都采用Hangouts的模式，會議主講人顯示圖像顯示比較大，其他人的相對比較小，很多其他用戶可能關(guān)閉了圖像功能，僅留語音功能。另外，還有的開源視頻會議系統(tǒng)，例如，jitsi，它提供了更為靈活的優(yōu)化方式，根據(jù)自己的網(wǎng)絡(luò)環(huán)境和其必要性，用戶端可以靈活調(diào)整圖像質(zhì)量。這樣就更加保證了會議的穩(wěn)定性。

當(dāng)然，如果用戶都開啟了攝像頭，整個測試的數(shù)據(jù)肯定會完全不同。通過以上數(shù)據(jù)可以看出，事實(shí)上，視頻會議支持的人數(shù)在MCU和SFU環(huán)境中是完全不同的。如果是MCU的話，支持人數(shù)更多取決于MCU本身的支持能力。如果是SFU的話，讀者可能需要考慮SFU的部署環(huán)境設(shè)置，客戶端的能力，SFU的級聯(lián)配置。另外，如果讀者部署在云平臺的話，例如CPaaS，用戶還要考慮平臺的支持能力。

50 participants in a single session

幾個開源的視頻會議平臺所支持的人數(shù)以及拓展支持

平臺名稱支持人數(shù)（建議使用人數(shù)/測試用戶）攝像頭數(shù)量拓展支持（會議房間是否可以調(diào)整）Jitsi

75/35/測試1000-4000用戶120用戶-靜音5攝像頭支持均衡負(fù)載，HAbigbluebutton（BBB）150/200150-<10攝像頭HA拓展支持更多會議房間/用戶

multiparty-meeting（MM）

100用戶/測試用戶/2000用戶（MX）135用戶-<10攝像頭支持HA均衡負(fù)載

為了滿足更多的用戶需求，級聯(lián)方式是SFU使用的主要的配置方式：

如果使用MCU方式，或者需要單臺服務(wù)器支持更多用戶人數(shù)的話，部署視頻會議只能通過增加CPU的處理能力，增加帶寬和控制人數(shù)方式來進(jìn)行優(yōu)化。

Cascading/媒體服務(wù)器分布式拓展

除了前面筆者討論的畫面布局問題帶來的視頻會議服務(wù)器的性能影響以外，如果視頻會議需要拓展支持的話，特別是SFU模式下的拓展支持，級聯(lián)的技術(shù)架構(gòu)和數(shù)據(jù)延遲也會帶來視頻會議的穩(wěn)定性問題。在實(shí)際生產(chǎn)環(huán)境中，我們自己也經(jīng)常會遇到會議狀態(tài)的不確定性：會議人數(shù)很難確定，會議人員地理位置很難確定，終端網(wǎng)絡(luò)質(zhì)量和終端處理能力。這樣就會導(dǎo)致視頻會議的不穩(wěn)定性和潛在問題。從幾個會議人員一下子攀升到幾十個或者上百個，甚至于上千人數(shù)等問題。

當(dāng)會議人數(shù)達(dá)到一定的數(shù)量時，視頻會議服務(wù)器端網(wǎng)絡(luò)帶寬和技術(shù)架構(gòu)肯定會受到極大沖擊。一般的解決辦法可以通過限制會議人數(shù)，在確認(rèn)的人數(shù)基礎(chǔ)上增加帶寬，設(shè)置I-frame控制丟包，針對流媒體支持，支持WebRTC的前向糾錯（FEC），通過WebRTC客戶端支持圖像質(zhì)量特征設(shè)置支持。為了完全實(shí)現(xiàn)視頻會議的拓展和HA服務(wù)，幾乎所有開源的WebRTC視頻服務(wù)器或者媒體服務(wù)器都可以通過不同的方式實(shí)現(xiàn)拓展。以下就是一個Jitsi實(shí)現(xiàn)級聯(lián)的技術(shù)架構(gòu)示例，通過Jitsi會議橋來創(chuàng)建不同的拓展和HA高可靠性部署。

當(dāng)然，這種級聯(lián)部署方式仍然可能會出現(xiàn)其他的問題，比如，會議人員的地理位置的不確定導(dǎo)致的數(shù)據(jù)交互延時，還有丟包問題，RTP媒體流延遲，TURN服務(wù)器解析DNS的延遲。在以下示例中，Jitsi的jicofo作為信令服務(wù)器和jvb（jitsi-videobridge） 媒體服務(wù)器進(jìn)行拓展交互，這樣可以達(dá)到最佳優(yōu)化效果。

除了在平臺進(jìn)行拓展處理以外，底層服務(wù)器端也可能進(jìn)行優(yōu)化拓展。

另外，在WebRTC的視頻會議或者媒體服務(wù)器端，一個非常消耗CPU資源的處理就是編碼轉(zhuǎn)換。為了保證媒體服務(wù)器的穩(wěn)定性和可拓展性，一些WebRTC服務(wù)器也充分使用了拓展的技術(shù)架構(gòu)，例如kurento的媒體服務(wù)器(底層是GStreamer)，然后通過底層的拓展來實(shí)現(xiàn)人群跟蹤檢測，車牌識別等具體的業(yè)務(wù)場景。在各種WebRTC服務(wù)器對比中，Kurento服務(wù)器端對各種場景和中間件處理比較靈活。其實(shí)，這種特性也是因?yàn)镵urento本身特性決定的，應(yīng)該不能說是它的一個優(yōu)點(diǎn)。Kurento本身的設(shè)計(jì)初衷就是支持不同媒體服務(wù)器場景的，因此相對比較靈活，其他的幾個媒體服務(wù)器更多側(cè)重于視頻會議一種業(yè)務(wù)，沒有其他的場景支持，因此也沒有kurento設(shè)計(jì)的那么靈活。

Kurento支持了多種非常具體的業(yè)務(wù)場景，包括人臉識別，車牌識別（支持IP攝像頭），物體跟蹤，人群監(jiān)控等場景，因此對中間件支持比較豐富，也支持了多種編碼格式和編碼轉(zhuǎn)換的處理。

根據(jù)研究人員Boni García在關(guān)于Kurento 的WebRTC 媒體服務(wù)器的論文中的總結(jié)，如果需要拓展媒體服務(wù)器的話，基于kurento的WebRTC服務(wù)器可以通過橫向增加服務(wù)器數(shù)量, 如果是云平臺的話增加實(shí)例，CPU，內(nèi)存來實(shí)現(xiàn)媒體服務(wù)器的拓展。具體的拓展方式以及其靈活性取決于WebRTC服務(wù)器的設(shè)計(jì)架構(gòu)，讀者可以參考此討論來進(jìn)行學(xué)習(xí)。關(guān)于kurento的背景介紹，讀者可以參考以前的文章：

kurento-開源WebRTC服務(wù)器-”一個半死不活"的開源項(xiàng)目

Scalelite是開源的均衡負(fù)載項(xiàng)目，它支持了BigBlueButto（BBB）的技術(shù)架構(gòu)，通過界面可以配置

Scalelite支持的BBB均衡負(fù)載技術(shù)架構(gòu)

它可以實(shí)現(xiàn)數(shù)據(jù)庫，Scalelite Server，Redis Cache 服務(wù)器。錄像/錄音共享，通過媒體服務(wù)器BBB拓展可以實(shí)現(xiàn)更多會議人數(shù)。

WebRTC服務(wù)器測試工具

在前面的章節(jié)中，我們討論了關(guān)于級聯(lián)的技術(shù)架構(gòu)HA處理方式的不同，還有媒體服務(wù)器拓展的方式。但是，這些拓展的技術(shù)架構(gòu)都是為了保證其WebRTC服務(wù)器的穩(wěn)定性，那么，如何針對WebRTC服務(wù)器進(jìn)行測試呢？其實(shí)，市場上和開源社區(qū)也提供了一些非常有效的測試工具，可以幫助用戶從不同角度來測試WebRTC服務(wù)器端的一些性能，以下是目前幾個主流的WebRTC 服務(wù)器測試工具：

• WebRTC-Analyzer：基于SimpleWebRTC開發(fā)的分析工具
• WebRTCBench：WebRTC基準(zhǔn)測試框架，由Parallel Architectures and Systems LAB開發(fā)，由Intel贊助
• Jitsi-Hammer：專門針對Jitsi開發(fā)的測試工具，可以創(chuàng)建會議室，播放視頻，克隆用戶，生成RTP流
• testRTC：商業(yè)版本的WebRTC視頻會議測試工具
• cosmosoftware：通過多種WebRTC場景測試工具，包括黑客工具，端對端加密服務(wù)，WebRTC視頻質(zhì)量評估工具。它支持目前幾個主流的WebRTC開源服務(wù)器（Janus, Jitsi, Medooze ，kurento等）
• ElasTest：開源基于云平臺業(yè)務(wù)的測試工具，支持WebRTC測試
• Selenium Framework：商業(yè)的自動測試工具，可以針對WebRTC進(jìn)行測試。
• Jattack：開源的針對WebRTC服務(wù)器端的壓力測試工具，但是目前僅支持Janus。

WebRTC測試架構(gòu)和應(yīng)用測試數(shù)據(jù)分享

筆者在前面討論了幾個關(guān)于WebRTC的性能的重要指標(biāo)以及相關(guān)的測試工具。但是，如果我們看一些測試分享時，我們?nèi)匀话l(fā)現(xiàn)，測試人員進(jìn)行的測試都是從不同的角度進(jìn)行的。事實(shí)上，業(yè)內(nèi)很多研究人員以及提出了比較完整的WebRTC測試技術(shù)架構(gòu)，測試人員可以從這個技術(shù)架構(gòu)中選擇不同的角度進(jìn)行測試。Boni García發(fā)布了關(guān)于WebRTC 測試的挑戰(zhàn)和實(shí)踐解決辦法，如果讀者計(jì)劃對WebRTC進(jìn)行測試的話，可以參考這個測試架構(gòu)進(jìn)行測試。

WebRTC 測試技術(shù)架構(gòu)

在實(shí)際的測試數(shù)據(jù)中，測試結(jié)果以及相關(guān)測試包括網(wǎng)絡(luò)帶寬的結(jié)果影響參數(shù)（編碼類型，分辨率，F(xiàn)rame rate，圖像大小，呼叫量），用戶人數(shù)，呼叫創(chuàng)建耗時，瀏覽器類型，媒體服務(wù)器類型（MCU/SFU），平臺部署方式（容器/虛擬機(jī)/云平臺），時延，視頻質(zhì)量等對比，CPU消耗，內(nèi)存消耗，QoS/QoE。Muhammad Shahid在他們團(tuán)隊(duì)的論文中討論了關(guān)于視頻會議QoS和QoE的相關(guān)測試參數(shù)，在進(jìn)行測試時也需要按照這些參數(shù)對比測試。

下面，筆者分享一些不同測試結(jié)果，讀者通過這些結(jié)果可以基本上了解相關(guān)WebRTC性能以及完整的相關(guān)要素，這些數(shù)據(jù)具有一定的參考意義。

瀏覽器是WebRTC呼叫中非常敏感的終端，很多WebRTC功能經(jīng)常受限于瀏覽器的版本。WebRTC應(yīng)用環(huán)境中，使用不同瀏覽器實(shí)現(xiàn)的信令創(chuàng)建結(jié)果。

臉部識別的CPU消耗

內(nèi)存消耗

存儲設(shè)備使用情況

網(wǎng)絡(luò)帶寬使用情況

http://www.kurento.org/blog/kurento-webrtc-gateway-ip-cameras

Sajjad Taheri發(fā)布了關(guān)于針對WebRTC性能測試的基礎(chǔ)測試方法，他不同終端環(huán)境下WebRTC呼叫初始時間，ICE創(chuàng)建時間等做了非常深入的研究調(diào)查。這也是很多WebRTC用戶經(jīng)常會遇到的問題，為什么WebRTC呼叫時間總是很長的一個合理的解釋。

關(guān)于ICE創(chuàng)建/offer/answer時間

不同網(wǎng)絡(luò)環(huán)境中ICE打洞時間耗費(fèi)

不同終端VP8編碼解碼渲染執(zhí)行情況

Emmanuel Andr′e針對不同開源WebRTC 媒體服務(wù)器SFU模式下的對比測試，包括了加載不同數(shù)量的用戶進(jìn)行測試，傳輸結(jié)果，時延和視頻效果評價得出來不同的測試結(jié)果。

Transmission bit rates （Jitsi，Janus，Medooze，Kurento和Mediasoup）結(jié)果

視頻會議評價結(jié)果：

WebRTC媒體服務(wù)器可以部署在物理機(jī)，也可以部署在虛擬機(jī)容器。這些不同平臺針對WebRTC服務(wù)器的性能有不同的影響。研究人員針對容器和虛擬機(jī)（KVM）上進(jìn)行了WebRTC媒體服務(wù)器的性能測試。使用的WebRTC媒體服務(wù)器是Kurento Media Server (KMS）。測試架構(gòu)如下：

根據(jù)此研究人員的測試，容器的整體性能優(yōu)于KVM，特別是實(shí)時通信應(yīng)用中時延的處理比KVM表現(xiàn)要好。

針對具體的WebRTC視頻會議服務(wù)器性能測試中，Jitsi的測試相對比較多，測試參數(shù)有非常明確。Boris Grozev 和 Emil Ivov根據(jù)以下幾個指標(biāo)對Jitsi進(jìn)行了測試評估（每秒中進(jìn)行的測試參數(shù)變量）

• conferences —活動會議數(shù)量
• endpoints — 所有會議加載的終端數(shù)量
• cpu_usage —CPU負(fù)載，包括CPU狀態(tài)
• network_in—接收的網(wǎng)絡(luò)數(shù)據(jù)bitrate
• network_out — 發(fā)出的bitrate
• bitrate —總和（network_in 和network_out），以Mbps計(jì)算。
• streams —Jitsi會議橋能夠處理的語音視頻數(shù)據(jù)流總和，這個數(shù)值取決于終端數(shù)量。

1056語音/視頻占用50Mbps帶寬

1056語音/視頻消耗20%CPU

其他語音/視頻終端加載的帶寬和CPU消耗狀態(tài)

關(guān)于針對視頻會議QoE的研究論文很多，有的研究論文針對H264高分辨率的研究，有的針對解碼算法進(jìn)行研究，還有的針對視頻質(zhì)量和壓縮進(jìn)行研究。這些視頻會議的算法研究都對QoE有非常大的影響。很多關(guān)于QoE評價方法，讀者有興趣的話，可以進(jìn)行進(jìn)一步研究。

常用的關(guān)于QoS和QoE評價方式中的參數(shù)

如果用戶需要進(jìn)行測試的話，在有限資源條件下盡量采用比較常用的參數(shù)，例如抖動，時延，帶寬和丟包測試。這里，我們分享Ahmad Vakili的關(guān)于QoE和Frame Rate，壓縮比，Bit Rate以及帶寬預(yù)估的研究結(jié)果。

WebRTC視頻會議可以使用不同的視頻編碼，目前使用最多的三種編碼中，它們都有各自的特點(diǎn)，特別是在網(wǎng)絡(luò)擁塞或者網(wǎng)絡(luò)帶寬有限時，它們的表現(xiàn)都不同。在720P測試環(huán)境下，三種視頻編碼的不同表現(xiàn)。H264相對VP8和V9，在帶寬有限時，它會產(chǎn)生更大的延遲，同時在分辨率不同的環(huán)境下，H264相對支持表現(xiàn)比較差。

在WebRTC視頻會議使用環(huán)境中，CPU和帶寬是非常重要的參數(shù)（內(nèi)存相對不太敏感），這兩個參數(shù)會直接影響視頻的質(zhì)量。以下是一個視頻會議測試中，使用SFU模式，不同帶寬環(huán)境下的視頻質(zhì)量表現(xiàn)（使用VP8編碼）。

設(shè)置為 low quality時的結(jié)果：

設(shè)置為high quality時的結(jié)果：

不同quality的jitter buffer delay結(jié)果

總結(jié)

在本文章介紹中，筆者主要分享了關(guān)于基于WebRTC的媒體服務(wù)器和視頻會議的介紹。首先，筆者介紹了分享了關(guān)于WebRTC性能的一些重要指標(biāo)，然后介紹了關(guān)于WebRTC目前研究的比較新的研究成果，影響WebRTC服務(wù)器執(zhí)行的幾個要素，關(guān)于視頻會議畫面布局帶來的影響，接下來，筆者介紹了關(guān)于WebRTC測試的幾個主要工具，最后筆者和讀者分享了WebRTC的測試架構(gòu)，以及不同研究人員針對不同環(huán)境和不同角度進(jìn)行的WebRTC的測試和相關(guān)性能報(bào)告。

雖然，筆者盡可能完整介紹了關(guān)于WebRTC服務(wù)器端性能測試的一些數(shù)據(jù)，但是，因?yàn)橘Y源有限，我們?nèi)鄙籴槍TUN和TURN的測試報(bào)告，也缺少基于App端的測試報(bào)告，還缺少關(guān)于WebRTC各種開源終端的測試報(bào)告。希望以后有機(jī)會能夠獲得更多資源來和讀者分享。

再次說明，如果讀者有興趣對某些數(shù)據(jù)或者測試手段進(jìn)行進(jìn)一步研究的話，建議讀者閱讀完整的論文原文和其相關(guān)研究論文。

參考資料：

www.w3.org

www.jitsi.org

www.jitsi.org.cn

Bart Jansen，Performance Evaluation of WebRTC based Video Conferencing

Sajjad Taheri，WebRTCBench: A Benchmark for Performance Assessment of WebRTC Implementations

Boni García，WebRTC Testing: State of the Art

Boris Grozev，Experimental Evaluation of Simulcast for WebRTC

Cristian Constantin Spoiala，Performance comparison of a WebRTC server on Docker versus Virtual Machine

Vamis Xhagjika???, Load and Video Performance Patterns of a Cloud Based WebRTC Architecture

Boris Grozev，Jitsi Videobridge Performance Evaluation

Emmanuel Andr′e， Comparative Study of WebRTC Open Source SFUs

for Video Conferencing

Boni García，Kurento: The Swiss Army Knife of WebRTC Media Servers

https://github.com/havfo/multiparty-meeting/blob/master/HAproxy.md

https://www.polycom.fr/content/dam/polycom/common/documents/whitepapers/benchmarking-videoconferencing-success-wp-enus.pdf

https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-video/212134-Video-Quality-of-Service-QOS-Tutorial.html#anc19

https://github.com/blindsidenetworks/scalelite

Boni García，WebRTC Testing: Challenges and Practical Solutions

https://www.red5pro.com/blog/guest-post-tashi-levent-levi-webrtc-scaling-challenges/

https://jitsi.org/blog/new-tutorial-video-scaling-jitsi-meet-in-the-cloud/

B.A. Jansen，Performance Analysis of WebRTC-based Video Conferencing