PROBLEM:
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的外出网速来维持这种广播 . 不能接受的 .
ORIGINAL QUESTION (OBSOLETE)
有可能以某种方式解决这个问题，所以B只在一些服务器上发送一个流，参与者只是从这个服务器中提取这个流吗？是的，这意味着此服务器上的传出速度必须很高，但我可以保持它 .
或许这意味着毁掉WebRTC的想法？
NOTES
根据最终客户的不良用户体验，Flash无法满足我的需求 .
SOLUTION (NOT REALLY)
26.05.2015 - 目前没有针对WebRTC的可扩展广播的解决方案，您根本不使用媒体服务器 . 市场上有服务器端解决方案以及混合（p2p服务器端，具体取决于不同的条件） .
虽然有一些有前途的技术，但他们需要回答这些可能的问题：延迟，整体网络连接稳定性，可扩展性公式（它们可能不是无限可扩展的） .
SUGGESTIONS
-
通过调整音频和视频编解码器来降低CPU /带宽;
-
获取媒体服务器 .
10 回答
Angel Genchev的答案似乎是正确的，然而，有一种理论架构，允许通过WebRTC进行低延迟广播 . 想象一下B（广播员）流到A1（与会者1） . 然后A2（与会者2）连接 . A1开始将从B接收的视频流传输到A2，而不是从B流式传输到A2 . 如果A1断开，则A2开始从B接收 .
如果没有延迟和连接超时，此架构可以工作 . 所以理论上它是正确的，但不是实际的 .
目前我正在使用服务器端解决方案 .
WebRTC可扩展解决方案市场上有一些解决方案 . 它们提供低延迟，可扩展的webrtc流 . 这是一些样本 . Janus，Jitsi，Wowza，Red5pro，Ant Media Server
我是Ant Media Server的开发人员，我们提供社区和企业版，包括android和iOS SDK . 如果我们能以某种方式帮助您，请告诉我们 .
正如它在这里所涉及的那样，你在这里尝试做的事情是不可能使用简单的，老式的WebRTC（严格的点对点） . 因为如前所述，WebRTC连接重新协商加密密钥以加密每个会话的数据 . 因此，您的广播公司（B）确实需要像参加者一样多次上传其视频流 .
但是，有一个非常简单的解决方案，它运行得很好：我测试了它，它被称为WebRTC网关 . Janus就是一个很好的例子 . 它是完全开源的（github repo here） .
其工作原理如下：您的广播公司联系了WebRTC的网关（Janus） . 所以有一个关键的协商：B安全地（加密流）传输到Janus .
现在，当与会者连接时，他们再次连接到Janus：WebRTC协商，安全密钥等 . 从现在开始，Janus将向每个与会者发回流 .
这很好用，因为广播公司（B）只将其流一次上传到Janus . 现在，Janus使用自己的密钥对数据进行解码，并可以访问原始数据（即RTP数据包），并可以将这些数据包发回给每个与会者（Janus负责为您加密） . 由于您将Janus放在服务器上，因此它具有很好的上载带宽，因此您可以流式传输到许多对等端 .
所以，是的， does 涉及一个服务器，但是该服务器会说WebRTC，而你"own"它：你实现了Janus部分，所以你不必担心数据损坏或中间人 . 当然，除非您的服务器受到损害 . 但是你可以做很多事情 .
为了向您展示使用它是多么容易，在Janus中，您有一个可以调用的函数
incoming_rtp()（和incoming_rtcp()），它为您提供了指向rt（c）p数据包的指针 . 然后，您可以将其发送给每个与会者（它们存储在Janus非常容易使用的_820930中） . Look here for one implementation of the incoming_rtp() function，a couple of lines below您可以看到如何将数据包传输给所有与会者，here您可以看到中继rtp数据包的实际功能 .这一切都很好，文档相当容易阅读和理解 . 我建议你从“回声”的例子开始，这是最简单的，你可以理解Janus的内部运作 . 我建议你编辑echo测试文件来制作你自己的，因为有很多冗余的代码要编写，所以你不妨从一个完整的文件开始 .
玩得开心！希望我帮忙 .
正如@MuazKhan所述：
https://github.com/muaz-khan/WebRTC-Scalable-Broadcast
在Chrome中工作，还没有音频广播，但它似乎是第一个解决方案 .
绝对可以完成 .
其他人也能够做到这一点：http://www.streamroot.io/
因特网无法进行广播，因为那里不允许进行IP UDP多播 . 但从理论上讲，它可以在局域网上实现 .
Websockets的问题在于你不允许这样做 .
WebRTC的问题在于它的数据通道使用一种SRTP形式，其中每个会话都有自己的 encryption 密钥 . 因此，除非有人"invents"或API允许在所有客户端之间使用一个会话密钥，否则多播是无用 .
AFAIK是目前唯一相关且成熟的实施方案，是Adobe Flash Player，自10.1版以来，它支持p2p多播用于点对点视频广播 .
http://tomkrcha.com/?p=1526 .
我的主人专注于使用WebRTC开发混合cdn / p2p直播流协议 . 我在http://bem.tv发表了我的第一个结果
一切都是开源的，我正在寻找贡献者！ :-)
有同伴辅助交付的解决方案，这意味着该方法是混合的 . 服务器和对等方都帮助分发资源 . 这是peer5.com和peercdn.com采取的方法 .
如果我们专门谈论直播，它看起来像这样：
Broadcaster将实时视频发送到服务器 .
服务器保存视频（通常还将其转码为所有相关格式） .
正在创建有关此实时流的元数据，与HLS或HDS或MPEG_DASH兼容
消费者浏览到相关的直播流，玩家获取元数据并知道接下来要播放的视频块 .
与此同时，消费者正在与其他消费者 Build 联系（通过WebRTC）
然后，播放器直接从服务器或对等端下载相关的块 .
根据实时流的比特率和 Spectator 的协作上行链路，遵循这样的模型可以节省高达约90％的服务器带宽 .
免责声明：作者正在Peer5工作
由于peer1只是调用getUserMedia（）的对等方，即peer1创建一个房间 .
因此，peer1捕获媒体并开始播放空间 .
peer2加入 Session 室并从peer1获取流（数据），并打开名为"peer2-connection"的并行连接
当peer3加入 Session 室并从peer2获取流（数据）并打开名为'peer3-connection'的并行连接时，依此类推 .
随着许多对等体彼此连接，该过程持续进行 .
因此，通过这种方式，可以在无限制的用户上传输单个广播，而不会出现任何带宽/ CPU使用问题 .
最后，以上所有内容均来自Link .
您正在描述使用具有一对多要求的WebRTC . WebRTC专为点对点流媒体而设计，但有些配置可让您在向许多 Spectator 提供视频的同时，从WebRTC的低延迟中受益 .
诀窍是不向每个 Spectator 征税流媒体客户端，就像你提到的那样，有一个"relay"媒体服务器 . 您可以自己构建，但老实说，最好的解决方案通常是使用像Wowza的WebRTC Streaming product这样的东西 .
要从手机有效地流式传输，你可以使用Wowza的GoCoder SDK，但根据我的经验，像StreamGears这样的更高级的SDK效果最好 .