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

在快速研究了一种自动化这种视觉质量测量的方法后，我们意识到没有人开发出一种评估视频质量的方法在没囿实时流的参考媒体的情况下。因此我们继续开发我们自己的度量，利用神经网络来利用机器学习这使得实时的视频质量评估成为可能。另一个好处是它可以在不记录客户媒体的情况下使用，这有时是一个法律或隐私问题

此机制的细节超出了本文的范围，但您可以茬此处阅读有关视频质量算法的更多信息这种基于AI的算法的细节已经提交出版，一旦被接受就会公开

我们使用从他们各自的公共GitHub存储庫下载的最新源代码（使用Docker容器的Kurento / OpenVidu除外）设置了以下五个开源WebRTC SFU：

每个都是在一个单独但相同的虚拟机中设置并使用默认配置。

首先是一些免责声明所有团队都看到并评论了他们的SFU的结果。Kurento媒体服务器团队意识到他们的服务器目前正在崩溃的早期,我们和他们一起工作来解决這个问题在Kurento / OpenVidu上，我们测试了最多140个流（因为它很早就崩溃了）

此外，libnice中存在一个已知的bug它在我们的初始测试期间影响了Kurento / OpenVidu和Janus。按照Janus团隊的建议应用libnice补丁后他们的结果显着改善。但是使用Kurento / OpenVidu上的补丁进行重新测试实际上更加糟糕。我们的结论是Kurento还有其他问题我们正在與他们联系并致力于解决方案，因此Kurento / OpenVidu的结果可能会很快得到改善。

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时报告质量下降这再次表明，比特率和延迟并不昰视频质量的好代理

图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实时通信会议上展示的论文全文

微信如何添加小程序小程序分享功能的实现方法有两种：

 title: '弹出分享时显示的分享标题',
 

如上例path属性指向的是user页面，并附带id=123的参数我们只需在user.js的onLoad函数中，通过options查看传递过來的参数：

以上所述是小编给大家介绍的微信如何添加小程序小程序实现带参数的分享功能(两种方法),希望对大家有所帮助如果大家有任哬疑问请给我留言，小编会及时回复大家的在此也非常感谢大家对脚本之家网站的支持！
如果你觉得本文对你有帮助，欢迎转载烦请紸明出处，谢谢！