转折点:WebRTC SFU负载测试(三)

免责声明 首先要向大家声明:所有团队均已查看、评估了SFU的结果。 早些时候,Kurento Media Server团队意识到他们的服务器崩溃,我们正在与他们合作解决这个问题。在Kurento / OpenVidu上,我们测试了最多140个数据流(因为它早前就崩溃了)。 此外,libnice中存在一个已知错误。在我们的初始测试期间,这一错误同时影响了Kurento / OpenVidu和Janu

转折点:WebRTC SFU负载测试(二)

选择测试客户端 负载测试通常由单个客户端完成,以便控制客户端的影响。理想情况下,你可以在单个虚拟机(VM)中并行运行测试客户端的许多实例。由于我们使用WebRTC,所以可以使用上述中的任一种浏览器。但是Edge和Safari只能运行一个实例,所以它们不是很适合用作测试。此外,Safari只能运行Apple硬件驱动的MacOS或iOS。如果你运行的是Windows或Linux,那么在AWS上生成一百

转折点——WebRTC SFU负载测试(一)

如果您想用WebRTC群聊,那您要用到的是选择性转发单元(SFU)。但是SFU的容量规划很难进行,因为我们需要估计它们的放置位置、带宽消耗以及所需服务器。 为了帮助网络架构师和WebRTC工程师完成此规划,webrtcHacks的撰稿人Alex Gouaillard博士和他CoSMo Software的团队把一个负载测试套件组合在一起来测量负载与视频质量。之后他们发布了所有主要开源WebRTC S

在WebRTC中实现P2P-SFU转换

WebRTC很厉害的一点是:它无需媒体路径中的任何服务器即可建立P2P连接。但是此连接不能大规模扩展多方音频/视频通话,因为大多数情况下,完整的N:N P2P连接所需的带宽和cpu太多了。 事实上,如果您支持多方通话的话,即使只有两位与会者也可以考虑使用P2P连接。在第三位与会者加入或需要启用某些录制或广播功能时切换回SFU即可。因为广播功能仅在SFU中可用。 实际上,最近几年在许多产品(Jits

WebRTC SFU中发送数据包丢失反馈

WebRTC SFU的职责之一是接收和发送RTCP数据包。RTCP数据包包括关于音频和视频流的不同类型的反馈,并且最重要的RTCP数据包是接收器报告(RR). RR数据包从媒体流接收器发送到该媒体流的发送者。在SFU的情况下,RR由SFU产生,并发送到媒体流发送器,并且还从每个流接收器发送到SFU。(如图1)。 RR数据包内发送的反馈包括用于计算网络引入的往返时间延迟,抖动和信息丢失。 这些RR数

二分浏览器错误

当大规模运行WebRTC时,最终会以遇到问题和频繁的回归结束。能够快速识别出问题所在是防止Chrome Stable中的归档降级或调整自己代码以避免问题的关键。Chrome的bisect-builds.py工具使这个过程比你想象中容易得多。来自appear.in的Arne为你提供了一个示例,说明他是如何使用它解决最近出现的问题。 本文中,我将会逐步解释Chrome的更改是如何触发appear.in

关于H.264我学到了什么(Tim Panton)

距离WebRTC编码战缓和结束已经有几年了。H.264已经存在了超过15年,因此很容易掩盖使它工作的错综复杂的问题。 Tim Panton正在进行一个无人机项目,他需要一个轻量级的H.264栈供WebRTC使用,因此他决定建造一个。这当然不是我最推荐的做法,但是Tim表示这可能是一个启发性的试验。在本文中,Tim一步一步向我们介绍他使视频工作的步骤。你还可以通过阅读介绍H.264的RFC规范来得到

使用级联SFU提高媒体质量和规模

部署WebRTC的媒体服务器有两个主要挑战,从一台服务器开始扩展,并且优化参加会议的用户的媒体延迟。尽管简单的碎片化方法像‘将X会议中的所有用户发送到服务器Y’容易实现水平扩展,在用户体验中,媒体延迟是一个关键因素,在这方面,此方法还远远不能达到最优效果。 将视频会议分布在距离用户很近的许多服务器上并且保持相互连接,同时解决了两个问题。来自Jitsi团队的Boris Grozev深度描述了级联SF

断点:WebRTC SFU负载测试(一)

如果你允许多人加入WebRTC通话,你可能会以SFU结束。计划如何分配容量比较困难-通常会进行估计,SFU应该放在哪里,它们将会消耗多少带宽,你需要何种服务器。 为了帮助网络架构和WebRTC工程师作出决定,Alex博士和他的CoSMo Softwae团队将负载测试元件放在一起来测量负载和视频质量。他们公布了所有主流的开源WebRTC SFU的测试结果。这个元件基于KITE并且在webrtc.or

WebRTC vs Zoom,哪一个具有更好的视频质量?

WebRTC vs Zoom? WebRTC很不错, 但是你早就知道了,不是么? 我们不止一次被告知这个视频会议供应商或者那个供应商很不错。它们提供最好的画质,最好的体验。它们的视频会议效果可以比别人更好。 我甚至曾经接到了一个公司的电话,向我解释他是如何提供一个比Skype或者Google Hangouts更好的1对1视频质量。它们使用WebRTC实现。 但是我偏离话题了。 就像其他人一样,我被

近期热门

有奖小调查

1 分钟回答 3 个小问题,让内容更符合你的 WebRTC 学习与开发期望。
每个月最后一天会随机抽出 5 名获奖者,并通过邮件联系送上奖品。
填写问卷