谁是最好的WebRTC SFU?

  1. 云栖社区>
  2. 博客>
  3. 正文

谁是最好的WebRTC SFU?

livevideostack 2018-10-30 07:30:00 浏览3168
展开阅读全文
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/83543056

如果你计划在WebRTC中有多个参与者,那么最终可能会使用选择性转发单元(SFU)。webrtcHacks的撰稿人 Alex Gouaillard和他的CoSMo Software团队组建了一个负载测试套件来测量负载与视频质量,并发布了所有主要开源WebRTC SFU的结果。LiveVideoStack对原文进行的摘译。


文 / Alex Gouaillard

译 / 元宝

原文 https://webrtchacks.com/sfu-load-testing/


首先要注意一个重要的问题——问什么样的SFU是最好的就像问什么样的车是最好的。如果你只想快点,那么你应该买一辆一级方程式赛车,但这不会帮助你送孩子上学。供应商从不对这些类型的测试感到兴奋,因为它把它们的功能归结为几个性能指标。这些指标可能不是其设计标准的主要部分,而且很多时候他们并不是那么重要。特别是对于WebRTC SFU,因为您可以在SFU上加载很多流,所以可能存在有许多弹性,用户行为和成本优化的原因。负载测试也不会深入研究端到端用户体验、开发的易用性,或者所有其他能够成功实现服务的功能元素。最后,像这样发表的报告代表了一个时间点——这些系统一直在改进,所以今天的结果可能会更好。


640?wx_fmt=png


介绍


在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个同步用户。


下图显示了测试平台中的元素:


640?wx_fmt=png


度量


大多数对可伸缩性问题感兴趣的人都会在“负载”(流、用户、房间…)增加时测量服务器的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 - 我们的算法不需要参考


640?wx_fmt=png 


图1:基于不同比特率对各种视频质量度量进行基准测试


注意,质量分数和比特率之间的关系不是线性的。如果您从参考值(1.7Mbps)开始缓慢地减少带宽,那么质量分数只会略微下降,直到它达到一个低比特率阈值,然后急剧下降。要降低10%的感知视频质量,需要根据WMAF将带宽减少到250Kbps,根据SSIM将带宽减少到150k,根据NARVAL将带宽减少到100k。


对SFU的测试也显示出同样的模式。图2给出了比特率作为每个SFU参与者数量的函数。可以看到,WebRTC的拥塞控制算法在早期(大约250名参与者)就开始运行,以保持比特率。然而,图3显示了延迟的线性增长。尽管带宽减少,延迟增加,但是在图4中显示的视频质量度量只在带宽低于200k时报告质量下降。这再次表明,比特率和延迟并不是视频质量的好代理。


640?wx_fmt=png


图2:JItsi在240名参与者失败。Kurento / OpenVidu很早就遇到了问题。Janus和mediasoup似乎比Medooze更好。它似乎与更好的CPU优化有关,因为拐点与各个CPU的饱和度相关。


640?wx_fmt=png


图3:JItsi在240名参与者失败,Kurento / OpenVidu在50左右出现问题。否则SFU表现出类似的行为。


640?wx_fmt=png


图4:视频质量仅在实验结束时下降,表明拥塞控制机制正在完成其工作,并设法做出正确的妥协,以便在调整其他参数的同时保持感知质量高。


测试过程中SFU的改进


除了上述结果本身之外,有趣的是,我们可以看到这项研究所引发的结果的进展。仅仅是提高知名度,就允许各自的团队解决最严重的问题。


你也可以观察到Janus很快就被限制了。他们已经在一个外部库中确定了这个瓶颈,以及一个可能的解决方案,但从未真正评估过真正的影响。我们可以清楚地看到这一节中的图(第一次运行)和前一节中的图(最新结果)之间的区别,Janus似乎表现最好。 


640?wx_fmt=png


比特率作为负载的函数。


之前(左)和之后(右)将补丁应用于Janus和Jitsi。我们还添加了mediasoup结果(绿色)。Medooze和Kurento / OpenVidu结果在两个图中都是相同的,因为第二次没有更好的结果。


640?wx_fmt=png


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)摘要。

网友评论

登录后评论
0/500
评论
livevideostack
+ 关注