One-to-Many Broadcasts with WebRTC

Learn more about WebRTC at Streaming Media East.

看完整的视频和其他亮点从流媒体西部连接上 Streaming Media's YouTube channel.

阅读这段视频的完整文本:

Robert Reinhardt: 传统的一对多广播看起来很像这样, 当涉及到一对多广播时，这仍然是许多设置正在做的事情. 我们有一个RTMP Publish进入某种媒体服务器摄取. There's a CDN in front of it. 它会处理所有HTTP边缘缓存，然后发送到HLS. 这是一个可靠的工作流程，对我来说，这就是它的样子. 我们在这个堆栈中有知道如何玩这个游戏的供应商. 我并不是想在这里指责供应商. 这张幻灯片是我从不同的演讲中整理出来的. 但我有AJA或Videon的设备知道如何用那种语言交谈, RTMP进入运行在Amazon EC2上的Wowza GPU, 我有CloudFront在前面负责HLS的分发给成千上万的观众. 我们有玩家技术栈来处理这个问题.

所以我现在有意将其与WebRTC进行对比, 因为它仍然是一个新来的孩子. It's been around for a long time, 但当谈到人们可以信赖的知名品牌时——这对在座的每个人来说基本上都是一个机会, 这仍然是一条需要铺设的道路, 希望不是出于好意, 因为我们知道那条路通向哪里. 但是有了WebRTC，你可以做同样的事情. 你可以有一个WebRTC客户端，推送到一个WebRTC网关，很多人都在监视WebRTC. 我说过的牛拍卖会，这就是我们正在做的. 我们有一个在浏览器中运行的WebRTC发布者，它推送到一个WebRTC网关. 每个人都可以连接并以低延迟观看，并且往返时间非常短. 没有太多的互动. They're not videoconferencing. 这是一个非常简单的架构.

This can be a problem to scale, 所以如果你需要和成千上万的人一起做这个你可能无法用一个盒子把它拉上来, if you're doing it in the hundreds, 然后，您可能可以使用更简化的体系结构来执行此操作. But as you start to scale We RTC, 你必须开始研究不同的模式，也许还要考虑现有的云服务.

Again, 当然你可以用WebRTC做多对多, 让人们以客户的身份相互交流, we're all publishing streams, we're all receiving streams. 这就是多对多关系. 有不同的变体，但我有意省略了这个堆栈上的供应商. 我并不是说没有好的解决方案. I've worked with Millicast. I've worked with Frozen Mountain. 我用过Red5 Pro和Wowza. 我开始在Janus项目上得到更多的工作. 但这并不像JW Player这样久经考验的真实名字，或者我们所知道的那些在行业中已经存在很长时间的名字. 这种情况将会改变，所以情况将会迅速改变. COVID当然也在加速这一进程.