谁是最好的WebRTC SFU？
如果你計劃在WebRTC中有多個參與者，那么最終可能會使用選擇性轉發單元(SFU)。webrtcHacks的撰稿人 Alex Gouaillard和他的CoSMo Software團隊組建了一個負載測試套件來測量負載與視頻質量，并發布了所有主要開源WebRTC SFU的結果。LiveVideoStack對原文進行的摘譯。
文 / Alex Gouaillard
譯 / 元寶
原文 https://webrtchacks.com/sfu-load-testing/
首先要注意一個重要的問題——問什么樣的SFU是最好的就像問什么樣的車是最好的。如果你只想快點，那么你應該買一輛一級方程式賽車，但這不會幫助你送孩子上學。供應商從不對這些類型的測試感到興奮，因為它把它們的功能歸結為幾個性能指標。這些指標可能不是其設計標準的主要部分，而且很多時候他們并不是那么重要。特別是對于WebRTC SFU，因為您可以在SFU上加載很多流，所以可能存在有許多彈性，用戶行為和成本優化的原因。負載測試也不會深入研究端到端用戶體驗、開發的易用性，或者所有其他能夠成功實現服務的功能元素。最后，像這樣發表的報告代表了一個時間點——這些系統一直在改進，所以今天的結果可能會更好。
介紹
在discussion-webrtc郵件列表上的一個反復出現的問題是“什么是最好的SFU”。這總是會產生來自各個SFU供應商和團隊的響應。顯然，它們不可能同時是正確的！
你可以在這里檢查整個線程。Chad Hart隨后帶著對話友好地回答了這個問題，并表示需要:
在任何情況下，我認為我們需要全局（同樣適用于所有）可重現且無偏見（可用的源代碼，并且每個供應商可以根據需要調整其安裝）基準，以獲得多個可伸縮性指標。
三年后，我和我的團隊建立了這樣一個基準系統。我將解釋這個系統是如何工作的，并在下面展示我們的一些初步結果。
問題
一些SFU供應商提供負載測試工具。Janus有Jattack。Jitsi有jitsi-hammer，甚至發表了他們的一些研究成果。Jitsi尤其在透明度方面做了大量工作，提供了可靠的數據和足夠的信息來重現結果。然而，并不是所有的供應商都有這些工此外，每個工具都旨在為自己的環境回答略有不同的問題，例如：
所選類型和給定帶寬限制的單個服務器實例可以處理多少個流？
我可以在同一個實例上支持多少用戶？
我可以在一個會議中支持多少用戶？
等等…
沒有辦法進行真正的比較研究——一個獨立可重復且無偏見的研究。這種固有的模糊性也為一些人的一些令人不快的行為打開了大門，他們意識到自己可以逃避任何索賠，因為沒有人能真正檢查他們。我們想要產生一些結果，人們不需要承擔責任，可以通過同行評議。
什么用例？
要想對“什么是最好的SFU？”有一個很好的答案，你需要解釋你打算用它做什么。
我們選擇研究似乎最受關注的兩個用例，或者至少是那些在discuss-webrtc上產生最多流量的用例：
1. 視頻會議——多對多，均等，一個參與者一次發言（希望如此），
2. 媒體流——一對多，單向
大多數視頻會議問題都集中在單個服務器實例上。在給定的會議中有20多人通常是很多人。相關研究表明，在大多數社交案例中，大多數呼叫都是1-1，平均值大約為3.這種配置非常適合任何公共云提供商中的一個小型實例（只要你獲得1Gbps NIC ）。然后，您可以使用非常簡單的負載平衡和水平可伸縮性技術，因為發送者與觀看者的比例很少。另一方面，媒體流通常涉及從單個源流向成千上萬的觀眾。這需要多服務器層次結構。
我們希望適應不同的測試場景，并在幾個WebRTC服務器上以相同的方式實現它們，這樣唯一的區別就是所測試的系統，并且結果不會有偏差。
測試套件
在與谷歌和其他許多公司的合作下，我們開發了KITE，這是一個測試引擎，它可以讓我們輕松地支持各種客戶端——瀏覽器和跨移動或桌面的本機客戶端——以及各種測試場景。它被用來測試WebRTC的實現，每天都在不同的瀏覽器上運行。
選擇測試客戶端
負載測試通常使用單個客戶機來控制客戶機的影響。理想情況下，您可以在單個虛擬機中并行運行測試客戶機的多個實例。由于這是WebRTC，所以使用其中一個瀏覽器是有意義的。Edge和Safari只局限于一個進程，這并不使它們非常適合。此外，Safari只運行MacOS或iOS，而iOS只在蘋果硬件上運行。如果運行的是Windows或Linux，那么在AWS上生成100萬個虛機相對比較容易。要安裝100萬臺Mac、iPhone或iPad進行測試，難度和成本都要大得多。
這樣你就有了Chrome或Firefox，可以同時運行多個實例。我們認為Chrome的webdriver實現更容易管理，需要處理的標志和插件更少(比如H264)，所以我們選擇使用Chrome。
被測系統
我們測試了以下SFU：
Janus
Jitsi
Kurento
mediasoup
Medooze
為了確保每個SFU都顯示出最佳結果，我們聯系了每個項目背后的團隊。我們提議讓他們自己設置服務器或連接到服務器并檢查他們的設置。我們也分享了結果，以便他們發表評論。這確保我們正確配置每個系統以便為我們的測試提供最佳處理。有趣的是，在這項研究的過程中，我們發現了一些bug，并與團隊一起改進了他們的解決方案。這將在最后一節中詳細討論。
測試設置
我們使用以下方法將流量增加到高負載。首先，我們在每個視頻會議室中每次只使用一個用戶，直到用戶總數達到7個。我們重復這個過程，直到達到目標用戶總數。接近500個同步用戶。
下圖顯示了測試平臺中的元素：
度量
大多數對可伸縮性問題感興趣的人都會在“負載”(流、用戶、房間…)增加時測量服務器的CPU、RAM和帶寬占用。這是一種傳統的方法，它假設流的質量、比特率都保持不變。
WebRTC的編碼引擎使得這個問題更加復雜。WebRTC包括帶寬估計、比特率適應和總體擁塞控制機制，不能假定在整個實驗過程中流將保持不變。除了通常的指標之外，測試人員還需要記錄客戶端指標，比如發送的比特率、帶寬估計結果和延遲。關注視頻質量也很重要，因為它可能會在CPU、RAM和/或服務器帶寬飽和之前下降。
在客戶端，我們最終測量了以下內容：
成功率和失敗率（凍結視頻，或沒有視頻）
發送者和接收者比特率
潛伏
視頻質量（下一節將詳細介紹）
在服務器端測量不同的度量標準就像自己匯集getStats API或集成callstats.io之類的解決方案一樣簡單。在我們的例子中，我們衡量：
CPU占用空間，
RAM足跡，
入口和出口帶寬進出，
流數量，
以及一些其他不太相關的指標。
由于篇幅限制，上述指標未在科學文章中發布，但應在隨后的研究報告中發布。除視頻質量外，所有這些指標都很容易制作和測量。什么是視頻質量的客觀衡量標準？存在幾種視頻質量代理，例如Google渲染時間，接收幀數，帶寬使用情況，但這些代理都沒有給出準確的測量結果。
視頻質量指標
理想情況下，當存在缺陷時，視頻質量指標在視覺上是顯而易見的。這將使我們能夠衡量彈性技術的相對好處，例如彈性視頻編碼(SVC)，從概念上講，輸出視頻與抖動、丟包等編碼方法的相關性較弱。有關視覺比較的一個很好的例子，請參閱Agora的以下視頻：
https://www.youtube.com/watch?v=M71uov3OMfk
在快速研究了一種自動化這種視覺質量測量的方法后，我們意識到沒有人開發出一種評估視頻質量的方法，在沒有實時流的參考媒體的情況下。因此，我們繼續開發我們自己的度量，利用神經網絡來利用機器學習。這使得實時的視頻質量評估成為可能。另一個好處是，它可以在不記錄客戶媒體的情況下使用，這有時是一個法律或隱私問題。
此機制的細節超出了本文的范圍，但您可以在此處閱讀有關視頻質量算法的更多信息。這種基于AI的算法的細節已經提交出版，一旦被接受就會公開。
告訴我結果
我們使用從他們各自的公共GitHub存儲庫下載的最新源代碼（使用Docker容器的Kurento / OpenVidu除外）設置了以下五個開源WebRTC SFU：
Jitsi Meet（JVB版本0.1.1077），
Janus Gateway（版本0.4.3）及其視頻室插件，
Medooze（版本0.32.0） SFU應用程序，
Kurento（來自OpenVidu Docker容器，Kurento Media Server版本6.7.0），
mediasoup（版本2.2.3），
每個都是在一個單獨但相同的虛擬機中設置并使用默認配置。
免責聲明
首先是一些免責聲明。所有團隊都看到并評論了他們的SFU的結果。Kurento媒體服務器團隊意識到他們的服務器目前正在崩潰的早期,我們和他們一起工作來解決這個問題。在Kurento / OpenVidu上，我們測試了最多140個流（因為它很早就崩潰了）。
此外，libnice中存在一個已知的bug，它在我們的初始測試期間影響了Kurento / OpenVidu和Janus。按照Janus團隊的建議應用libnice補丁后，他們的結果顯著改善。但是，使用Kurento / OpenVidu上的補丁進行重新測試實際上更加糟糕。我們的結論是Kurento還有其他問題。我們正在與他們聯系并致力于解決方案，因此，Kurento / OpenVidu的結果可能會很快得到改善。
最新版本的Jitsi Videobridge(到本文發表時為止)在240個用戶時總是變得不穩定。Jitsi團隊已經意識到了這一點并正在解決這個問題。但是，他們指出，他們的一般建議是依賴于使用此處描述的大量較小實例的水平擴展。請注意，以前的版本(如兩個月前的版本)沒有這些穩定性問題，但表現不佳(請參閱下一節中的更多內容)。我們選擇保留0.1.1077版本，因為它包含使simulcast更好，并顯著改善了結果。
另請注意，自測試以來，幾乎所有這些產品都有版本發布。自從此處顯示的測試結果以來，一些已經做了改進
測量
作為參考點，我們選擇了一種常用的視頻測試序列，并使用多種視頻質量評估指標計算其視頻質量得分：
SSIM - 一種比較失真圖像與其原始圖像之間差異的常用指標
VMAF -Netflix使用和開發的一些指標的綜合衡量標準
NARVAL - 我們的算法不需要參考
?
圖1：基于不同比特率對各種視頻質量度量進行基準測試
注意，質量分數和比特率之間的關系不是線性的。如果您從參考值(1.7Mbps)開始緩慢地減少帶寬，那么質量分數只會略微下降，直到它達到一個低比特率閾值，然后急劇下降。要降低10%的感知視頻質量，需要根據WMAF將帶寬減少到250Kbps，根據SSIM將帶寬減少到150k，根據NARVAL將帶寬減少到100k。
對SFU的測試也顯示出同樣的模式。圖2給出了比特率作為每個SFU參與者數量的函數。可以看到，WebRTC的擁塞控制算法在早期(大約250名參與者)就開始運行，以保持比特率。然而，圖3顯示了延遲的線性增長。盡管帶寬減少，延遲增加，但是在圖4中顯示的視頻質量度量只在帶寬低于200k時報告質量下降。這再次表明，比特率和延遲并不是視頻質量的好代理。
圖2：JItsi在240名參與者失敗。Kurento / OpenVidu很早就遇到了問題。Janus和mediasoup似乎比Medooze更好。它似乎與更好的CPU優化有關，因為拐點與各個CPU的飽和度相關。
圖3：JItsi在240名參與者失敗，Kurento / OpenVidu在50左右出現問題。否則SFU表現出類似的行為。
圖4：視頻質量僅在實驗結束時下降，表明擁塞控制機制正在完成其工作，并設法做出正確的妥協，以便在調整其他參數的同時保持感知質量高。
測試過程中SFU的改進
除了上述結果本身之外，有趣的是，我們可以看到這項研究所引發的結果的進展。僅僅是提高知名度，就允許各自的團隊解決最嚴重的問題。
你也可以觀察到Janus很快就被限制了。他們已經在一個外部庫中確定了這個瓶頸，以及一個可能的解決方案，但從未真正評估過真正的影響。我們可以清楚地看到這一節中的圖(第一次運行)和前一節中的圖(最新結果)之間的區別，Janus似乎表現最好。?
比特率作為負載的函數。
之前（左）和之后（右）將補丁應用于Janus和Jitsi。我們還添加了mediasoup結果（綠色）。Medooze和Kurento / OpenVidu結果在兩個圖中都是相同的，因為第二次沒有更好的結果。
RTT或延遲，作為負載的函數（對數標度）。之前（左）和之后（右）將補丁應用于Janus和Jitsi。我們還添加了mediasoup結果（綠色）。Medooze和Kurento / OpenVidu結果來自同一數據集。
最后，我們最初文章的一位審稿人指出，CoSMo的雇員塞爾吉奧?加西亞?穆里洛(Sergio Garcia Murillo)的Medooze最終成為了我們研究的重點，暗示了利益沖突可能導致的偏見。我們花了很大的努力來進行我們所有的測試，沒有偏見的透明。我認為在最新的結果中看到一些SFUs與Medooze持平或更好，消除了一些人可能有的最后的擔憂，這是令人振奮的。這對Medooze團隊來說也是個好消息——現在他們知道他們要做什么(比如Medooze 0.46的改進)，他們有了一個工具來衡量他們的進展。
結論
我們希望我們已經證明，由于KITE和CoSMo最近與WebRTC生態系統的作者合作開發的一些其他工具，現在相對容易實現對SFU的無偏見的比較測試。我們將繼續與不同的開源WebRTC SFU供應商合作，幫助他們改進他們的軟件。我們計劃盡可能多地使用用于生成這些結果的代碼公開，并且無論如何，以非營利的方式為公共研究人員提供對該工具的訪問。最終，我們希望將這些結果作為“實時”網頁托管，在新版本的軟件可用時，可以獲得新的結果。
請參閱本周在IIT實時通信會議上展示的論文全文
(https://www.cosmosoftware.io/publications/andre2018_Comparative_Study_of_SFUs.pdf)和幻燈片。
(https://www.cosmosoftware.io/publications/andre2018_slides_Comparative_Study_of_SFUs.pdf)摘要。
總結
以上是生活随笔為你收集整理的谁是最好的WebRTC SFU？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Hulu直播服务难点解析（三）：关键收获
- 下一篇： FFmpeg在Intel GPU上的硬件