实时通信的常见误区
2021-07-30
在最近Kranky Geek WebRTC演讲中，我谈到了自己对实时通信的一些误解。我在RTC领域工作了近十年，但直到去年我才明白，大家所了解的视频通话和流媒体共识并不是真的。比如： 两人之间的端对端连接能提供最好的效果 公共互联网比虚拟网络快 SFU架构（服务器/路由器中继）是小型团队的最佳选择。 在演讲中我提出，多个SFU，若通过软件定义和管理的虚拟网络连接，其效果远好于公共互联网上的端对端连
在SFU上实现RED音频冗余功能
2021-03-16
最近，Chrome添加了使用RFC 2198中定义的RED格式给音频流添加冗余的选项。Fippo之前写过一篇文章解释该过程和实现，建议大家研读。大致总结一下这篇文章的话，主要讲述了RED的工作原理是在同一个数据包中添加具有不同时间戳的冗余有效载荷。如果你在出现损耗的网络中丢失了一个数据包，若另一个数据包被成功接收，其中可能会含有丢失的数据，产生更好的音频质量。 上述假设发生在简化的一对一场景下，但
转折点：WebRTC SFU负载测试（三）
2020-04-03
免责声明 首先要向大家声明：所有团队均已查看、评估了SFU的结果。 早些时候，Kurento Media Server团队意识到他们的服务器崩溃，我们正在与他们合作解决这个问题。在Kurento / OpenVidu上，我们测试了最多140个数据流（因为它早前就崩溃了）。 此外，libnice中存在一个已知错误。在我们的初始测试期间，这一错误同时影响了Kurento / OpenVidu和Janu
转折点：WebRTC SFU负载测试（二）
2020-04-01
选择测试客户端 负载测试通常由单个客户端完成，以便控制客户端的影响。理想情况下，你可以在单个虚拟机（VM）中并行运行测试客户端的许多实例。由于我们使用WebRTC，所以可以使用上述中的任一种浏览器。但是Edge和Safari只能运行一个实例，所以它们不是很适合用作测试。此外，Safari只能运行Apple硬件驱动的MacOS或iOS。如果你运行的是Windows或Linux，那么在AWS上生成一百
转折点——WebRTC SFU负载测试（一）
2020-03-20
如果您想用WebRTC群聊，那您要用到的是选择性转发单元（SFU）。但是SFU的容量规划很难进行，因为我们需要估计它们的放置位置、带宽消耗以及所需服务器。 为了帮助网络架构师和WebRTC工程师完成此规划，webrtcHacks的撰稿人Alex Gouaillard博士和他CoSMo Software的团队把一个负载测试套件组合在一起来测量负载与视频质量。之后他们发布了所有主要开源WebRTC S
在WebRTC中实现P2P-SFU转换
2019-10-22
WebRTC很厉害的一点是：它无需媒体路径中的任何服务器即可建立P2P连接。但是此连接不能大规模扩展多方音频/视频通话，因为大多数情况下，完整的N：N P2P连接所需的带宽和cpu太多了。 事实上，如果您支持多方通话的话，即使只有两位与会者也可以考虑使用P2P连接。在第三位与会者加入或需要启用某些录制或广播功能时切换回SFU即可。因为广播功能仅在SFU中可用。 实际上，最近几年在许多产品（Jits
WebRTC SFU中发送数据包丢失反馈
2019-08-16
WebRTC SFU的职责之一是接收和发送RTCP数据包。RTCP数据包包括关于音频和视频流的不同类型的反馈，并且最重要的RTCP数据包是接收器报告(RR). RR数据包从媒体流接收器发送到该媒体流的发送者。在SFU的情况下，RR由SFU产生，并发送到媒体流发送器，并且还从每个流接收器发送到SFU。(如图1)。 RR数据包内发送的反馈包括用于计算网络引入的往返时间延迟，抖动和信息丢失。 这些RR数
二分浏览器错误
2019-06-11
当大规模运行WebRTC时，最终会以遇到问题和频繁的回归结束。能够快速识别出问题所在是防止Chrome Stable中的归档降级或调整自己代码以避免问题的关键。Chrome的bisect-builds.py工具使这个过程比你想象中容易得多。来自appear.in的Arne为你提供了一个示例，说明他是如何使用它解决最近出现的问题。 本文中，我将会逐步解释Chrome的更改是如何触发appear.in
关于H.264我学到了什么（Tim Panton）
2019-03-11
距离WebRTC编码战缓和结束已经有几年了。H.264已经存在了超过15年，因此很容易掩盖使它工作的错综复杂的问题。 Tim Panton正在进行一个无人机项目，他需要一个轻量级的H.264栈供WebRTC使用，因此他决定建造一个。这当然不是我最推荐的做法，但是Tim表示这可能是一个启发性的试验。在本文中，Tim一步一步向我们介绍他使视频工作的步骤。你还可以通过阅读介绍H.264的RFC规范来得到
使用级联SFU提高媒体质量和规模
2018-11-26
部署WebRTC的媒体服务器有两个主要挑战，从一台服务器开始扩展，并且优化参加会议的用户的媒体延迟。尽管简单的碎片化方法像‘将X会议中的所有用户发送到服务器Y’容易实现水平扩展，在用户体验中，媒体延迟是一个关键因素，在这方面，此方法还远远不能达到最优效果。 将视频会议分布在距离用户很近的许多服务器上并且保持相互连接，同时解决了两个问题。来自Jitsi团队的Boris Grozev深度描述了级联SF
近期热门
有奖小调查
1 分钟回答 3 个小问题，让内容更符合你的 WebRTC 学习与开发期望。
每个月最后一天会随机抽出 5 名获奖者，并通过邮件联系送上奖品。
填写问卷
Previous
Next
