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的想法？
[！ ]最新的问题
- 解决CPU /带宽 – 是否有无服务器解决scheme（又名组播或类似的东西）？
- 解决CPU – 是否有可能只编码一次stream并发送给同行？
- 解决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广播。
我的主人专注于开发使用WebRTC的混合cdn / p2p直播stream协议。 我在http://bem.tv发布了我的第一个结果;
一切都是开源的，我正在寻找贡献者！ 🙂
有同伴辅助交付的解决scheme，这意味着这种方法是混合的。 服务器和对等端都可以帮助分发资源。 这是peer5.com和peercdn.com采取的方法。
如果我们专门谈论现场直播，它会看起来像这样：
- 广播公司将实况video发送到服务器。
- 服务器保存video（通常也转码为所有相关的格式）。
- 正在创build有关此直播stream的元数据，与HLS或HDS或MPEG_DASH兼容
- 消费者在那里浏览相关的实时stream，播放器获取元数据，并知道下一个要播放的video块。
- 与此同时，消费者正在与其他消费者联系（通过WebRTC）
- 然后玩家直接从服务器或从同行下载相关的块。
遵循这样的模型可以节省高达约90％的服务器带宽，这取决于实况stream的比特率和观众的协同上行链路。
免责声明：作者在Peer5工作
天使Genchev的答案似乎是正确的，但是，有一个理论架构，允许通过WebRTC的低延迟广播。 想象一下B（广播公司）stream向A1（与会者1）。 然后A2（与会者2）连接。 而不是从B到A2stream，A1开始从B到A2接收streamvideo。 如果A1断开，则A2开始从B接收。
如果没有延迟和连接超时，这个架构可以工作。 所以理论上这是对的，但不是实际的。
目前我正在使用服务器端解决scheme。
