WebRTC - 可扩展的直播流广播/多播

Question

问题:

WebRTC为我们提供点对点视频/音频连接.它非常适合p2p通话,环聊.但是广播怎么样(一对多,例如,1到10000)？

假设我们有一个广播员"B"和两个参加者"A1","A2".当然它似乎是可以解决的:我们只用B连接B,然后用A2连接B. 因此B将视频/音频流直接发送到A1,将另一个流发送到A2.B发送两次流.

现在让我们想象有10000名与会者:A1,A2,...,A10000.这意味着B必须发送10000个流.每个流约为40KB/s,这意味着B需要400MB/s的外出网速来维持这种广播.不能接受的.

原始问题(已废除)

是否有可能以某种方式解决这个问题,所以B只在某个服务器上发送一个流,而与会者只是从这个服务器中提取这个流？是的,这意味着此服务器上的传出速度必须很高,但我可以保持它.

或者这可能意味着毁掉WebRTC的想法？

笔记

根据最终客户的不良用户体验,Flash无法满足我的需求.

解决方案(不是真的)

26.05.2015 - 目前没有针对WebRTC的可扩展广播的解决方案,您根本不使用媒体服务器.市场上有服务器端解决方案以及混合(p2p +服务器端,具体取决于不同的条件).

虽然有一些有前途的技术,如https://github.com/muaz-khan/WebRTC-Scalable-Broadcast,但他们需要回答这些可能的问题:延迟,整体网络连接稳定性,可扩展性公式(它们不是无限可扩展的).

几点建议

1. 通过调整音频和视频编解码器来降低CPU /带宽;
2. 获取媒体服务器.

Answer 1

由于这里几乎涵盖了这一点,因此无法使用普通的,老式的WebRTC(严格的点对点)来实现您在这里所要做的.因为如前所述,WebRTC连接重新协商加密密钥以加密每个会话的数据.因此,您的广播公司(B)确实需要像参加者一样多次上传其流.

但是,有一个非常简单的解决方案,它运行得很好:我测试过它,它被称为WebRTC网关.Janus就是一个很好的例子.它是完全开源的(这里是github repo).

其工作原理如下:您的广播公司联系了WebRTC的网关(Janus).所以有一个关键的协商:B安全地(加密流)传输给Janus.

现在,当与会者连接时,他们再次连接到Janus:WebRTC协商,安全密钥等.从现在开始,Janus将向每个与会者发回流.

这很有效,因为广播公司(B)只将其流一次上传到Janus.现在,Janus使用自己的密钥对数据进行解码,并可以访问原始数据(即RTP数据包),并可以将这些数据包发回给每个与会者(Janus负责为您加密).由于您将Janus放在服务器上,它具有很好的上传带宽,因此您可以流式传输到许多对等端.

所以是的,它确实涉及服务器,但该服务器会说WebRTC,并且您"拥有"它:您实现Janus部分,因此您不必担心数据损坏或中间人.当然,除非您的服务器受到损害.但是你可以做很多事情.

为了向您展示使用它是多么容易,在Janus中,您有一个可以调用的函数incoming_rtp()(和incoming_rtcp()),它为您提供指向rt(c)p数据包的指针.然后,您可以将其发送给每个与会者(它们存储在sessionsJanus非常容易使用).在这里寻找一个实现的incoming_rtp()功能,一对夫妇低于行的,你可以看到如何将数据包发送给所有与会者,并在这里你可以看到实际的功能中继的RTP包.

这一切都很好,文档相当容易阅读和理解.我建议你从"回声"的例子开始,它是最简单的,你可以理解Janus的内部运作.我建议你编辑echo测试文件来制作你自己的,因为有很多冗余的代码要编写,所以你不妨从一个完整的文件开始.

玩得开心!希望我帮忙.

Answer 2

正如@MuazKhan所说:

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast

在Chrome中工作,还没有音频广播,但它似乎是第一个解决方案.

可扩展的WebRTC点对点广播演示.

该模块简单地初始化socket.io并以一种方式对其进行配置,即单个广播可以通过无限用户进行中继,而不会出现任何带宽/ CPU使用问题.一切都发生在点对点!

绝对可以完成.
其他人也能够实现这一目标:http://www.streamroot.io/

Answer 3

AFAIK是目前唯一相关且成熟的实施方案,是Adobe Flash Player,自10.1版以来支持p2p多播用于点对点视频广播.

http://tomkrcha.com/?p=1526.

Answer 4

互联网上无法实现"可扩展"广播,因为那里不允许进行IP UDP多播.但从理论上讲,它可以在局域网上实现.
Websockets的问题在于您无法通过设计访问RAW UDP,因此不允许这样做.
WebRTC的问题在于它的数据通道使用一种SRTP形式,其中每个会话都有自己的加密密钥.因此,除非有人"发明"或API允许在所有客户端之间共享一个会话密钥,否则多播是无用的.

Answer 5

有同伴辅助交付的解决方案,这意味着该方法是混合的.服务器和对等方都帮助分发资源.这就是peer5.com和peercdn.com所采取的方法.

如果我们专门谈论直播,它看起来像这样:

1. Broadcaster将实时视频发送到服务器.
2. 服务器保存视频(通常还将其转码为所有相关格式).
3. 正在创建有关此实时流的元数据,与HLS或HDS或MPEG_DASH兼容
4. 消费者浏览相关的直播流,玩家获取元数据并知道接下来要播放的视频块.
5. 与此同时,消费者正在与其他消费者建立联系(通过WebRTC)
6. 然后,播放器直接从服务器或从对等端下载相关的块.

遵循这样的模型可以节省高达服务器带宽的约90%,这取决于直播的比特率和观众的协作上行链路.

免责声明:作者正在Peer5工作

Answer 6

我的主人专注于使用WebRTC开发混合cdn/p2p直播流协议.我在http://bem.tv上发表了我的第一个结果

一切都是开源的,我正在寻找贡献者!:-)