WebRTC – 可扩展的实况stream广播/多播

[! ]问题仍然是开放的

问题:

WebRTC为我们提供点对点video/audio连接。 这是完美的P2P呼叫,环聊。 但是广播(一对多,例如1比10000)呢?

假设我们有一个广播员“B”和两个与会者“A1”,“A2”。 当然,这似乎是可以解决的:我们只需要将B与A1连接,然后将B与A2连接。 所以B将video/audiostream直接发送到A1,将另一个stream发送到A2。 B发送stream两次。

现在让我们想象一下有10000个与会者:A1,A2,…,A10000。 这意味着B必须发送10000个stream。 每个stream〜40KB / s,这意味着B需要400MB / s的传出网速来维持这个广播。 不能接受的。

原始问题(已过时)

是否有可能以某种方式解决这个问题,所以B只发送一个stream在一些服务器上,与会者只是从这个服务器拉这个stream? 是的,这意味着在这个服务器上的传出速度必须很高,但我可以维护它。

或者,也许这意味着破坏WebRTC的想法?

[! ]最新的问题

  1. 解决CPU /带宽 – 是否有无服务器解决scheme(又名组播或类似的东西)?
  2. 解决CPU – 是否有可能只编码一次stream并发送给同行?
  3. 解决CPU /带宽 – 多播是绝对有可能的,但它实际上在实际工作(延迟,networking不稳定)?

笔记

对于最终用户而言,由于糟糕的用户体验,Flash无法满足我的需求。

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

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

由于这里已经涵盖了很多东西,所以您在这里尝试做的事情对于简单的老式的WebRTC(严格的点对点)来说是不可能的。 因为正如前面所说,WebRTC连接重新协商encryption密钥来encryption每个会话的数据。 因此,您的广播公司(B)确实需要上传其stream的次数与参加者的次数相同。

但是,有一个非常简单的解决scheme,效果很好:我testing了它,它被称为WebRTC网关。 Janus就是一个很好的例子。 这是完全开源( github回购在这里 )。

这工作如下:您的广播电台联系说WebRTC的网关(Janus)。 所以有一个关键的谈判:乙安全(encryptionstream)传输给Janus。

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

这很有效,因为广播公司(B)只上传一次stream到Janus。 现在,Janus使用自己的密钥对数据进行解码,并可以访问原始数据(即RTP数据包),并将这些数据包发回给每个与会者(Janus负责为您encryption)。 既然你把Janus放在服务器上,它的上传带宽非常好,所以你可以stream到很多同行。

所以是的,它涉及到一个服务器,但该服务器说WebRTC,你“拥有”它:你实施Janus部分,所以你不必担心数据损坏或中间人。 那么除非你的服务器受到了威胁,当然。 但是你可以做的事情太多了。

为了向您展示在Janus中使用它是多么容易,您可以调用一个名为incoming_rtp() (和incoming_rtcp() )的函数,从而为您提供一个指向rt(c)p数据包的指针。 然后,您可以将其发送给每个与会者(他们存储在Janus非常容易使用的sessions中)。 在这里查看incoming_rtp()函数的一个实现,在 下面的几行可以看到如何将数据包传输给所有与会者, 在这里您可以看到实际的函数来中继一个rtp数据包。

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

玩的开心! 希望我帮助。

互联网上不可能进行“可扩展的”广播,因为IP UDP广播不允许在那里。 但理论上在局域网上是可能的。
Websockets的问题是你没有通过devise访问RAW UDP,它不会被允许。
WebRTC的问题是数据通道使用一种SRTPforms,每个会话都有自己的encryption密钥。 因此,除非有人“发明”或API允许在所有客户端之间共享一个会话密钥,否则组播是无用的。

正如@Mazazhan在上面指出的那样:

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

在铬合作,并没有audio广播,但它似乎是第一个解决scheme。

可扩展的WebRTC对等广播演示。

这个模块简单地初始化socket.io,并以一种可以在无限制的用户中继单个广播而没有任何带宽/ CPU使用率问题的方式进行configuration。 一切都发生在同行之间!

在这里输入图像说明

这一定是可以完成的。
其他人也可以实现这一点: http : //www.streamroot.io/

AFAIK目前唯一相关且成熟的实现方式是Adobe Flash Player,它自10.1版以来支持P2P对等video广播。

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

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

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

有同伴辅助交付的解决scheme,这意味着这种方法是混合的。 服务器和对等端都可以帮助分发资源。 这是peer5.com和peercdn.com采取的方法。

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

  1. 广播公司将实况video发送到服务器。
  2. 服务器保存video(通常也转码为所有相关的格式)。
  3. 正在创build有关此直播stream的元数据,与HLS或HDS或MPEG_DASH兼容
  4. 消费者在那里浏览相关的实时stream,播放器获取元数据,并知道下一个要播放的video块。
  5. 与此同时,消费者正在与其他消费者联系(通过WebRTC)
  6. 然后玩家直接从服务器或从同行下载相关的块。

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

免责声明:作者在Peer5工作

天使Genchev的答案似乎是正确的,但是,有一个理论架构,允许通过WebRTC的低延迟广播。 想象一下B(广播公司)stream向A1(与会者1)。 然后A2(与会者2)连接。 而不是从B到A2stream,A1开始从B到A2接收streamvideo。 如果A1断开,则A2开始从B接收。

如果没有延迟和连接超时,这个架构可以工作。 所以理论上这是对的,但不是实际的。

目前我正在使用服务器端解决scheme。