WebRTC-可伸缩的实时流广播/多播

问题：

WebRTC为我们提供了对等视频/音频连接。非常适合p2p通话，环聊。但是广播（一对多，例如1-to-10000）又如何呢？

假设我们有一个广播公司“ B”和两个与会者“ A1”，“ A2”。当然，这似乎是可以解决的：我们只需将B与A1连接起来，然后将B与A2连接起来。因此，B直接将视频/音频流发送到A1，将另一个流发送到A2。B发送两次流。

现在，假设有10000位与会者：A1，A2，...，A10000。这意味着B必须发送10000个流。每个流约为40KB / s，这意味着B需要400MB / s的传出互联网速度来维持此广播。不能接受

原始问题（过时）

是否可以通过某种方式解决此问题，因此B在某个服务器上仅发送一个流，而与会者只是从该服务器中拉出该流？是的，这意味着该服务器上的传出速度必须很高，但是我可以维持它。

也许这意味着破坏WebRTC的想法？

笔记

根据最终用户的不良UX，Flash无法满足我的需求。

解决方案（并非完全如此）

2015年5月26日-目前尚无针对WebRTC的可伸缩广播的解决方案，您根本不需要使用媒体服务器。市场上有服务器端解决方案以及混合（p2p +服务器端，具体取决于不同的条件）。

尽管有一些很有前途的技术，例如https://github.com/muaz-khan/WebRTC-Scalable-Broadcast，但他们需要回答以下可能的问题：延迟，整体网络连接稳定性，可伸缩性公式（它们可能不是无限可伸缩的） ）。

建议

1. 通过调整音频和视频编解码器来减少CPU /带宽；
2. 获取媒体服务器。

由于这里已经介绍了很多内容，因此您无法在普通的，老式的WebRTC（严格来说是点对点）中尝试这样做。因为如前所述，WebRTC连接为每个会话重新协商加密密钥以加密数据。因此，您的广播公司（B）实际上确实需要将其流上载与参加者一样多。

但是，有一个非常简单的解决方案，效果很好：我已经对其进行了测试，它称为WebRTC网关。Janus是一个很好的例子。它是完全开源的（github仓库在这里）。

它的工作方式如下：您的广播公司联系使用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包。

一切都很好，文档很容易阅读和理解。我建议您从“ echotest”示例开始，这是最简单的示例，您可以了解Janus的内部工作原理。我建议您编辑回声测试文件以制作自己的文件，因为有很多多余的代码要编写，因此您最好从一个完整的文件开始。

玩得开心！希望我能帮上忙。

正如@MuazKhan上文所述：

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

可以在chrome中使用，目前还没有音频广播，但这似乎是第一种解决方案。

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

该模块只是简单地初始化socket.io并对其进行配置，以使单个广播可以在无限的用户上进行中继，而不会出现带宽/ CPU使用问题。一切都是对等的！

这绝对应该可以完成。
其他人也可以实现此目的：http : //www.streamroot.io/

AFAIK目前与此相关且成熟的唯一实现是Adobe Flash Player，该版本自10.1版以来就支持点对点视频广播的p2p组播。

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

由于Internet上不允许IP UDP多播，因此Internet上不可能进行“可伸缩”广播。但从理论上讲，它可以在局域网上进行。
Websockets的问题在于，您无权通过设计访问RAW UDP，并且将不允许这样做。
WebRTC的问题在于它的数据通道使用一种SRTP形式，其中每个会话都有自己的加密密钥。因此，除非有人“发明”或API允许一种在所有客户端之间共享一个会话密钥的方法，否则多播是无用的。

有对等辅助交付的解决方案，这意味着该方法是混合的。服务器和对等方均有助于分发资源。这就是peer5.com和peercdn.com所采用的方法。

如果我们专门谈论直播，它将看起来像这样：

1. 广播公司将实时视频发送到服务器。
2. 服务器保存视频（通常还会将其转码为所有相关格式）。
3. 正在创建有关此实时流的元数据，与HLS或HDS或MPEG_DASH兼容
4. 消费者浏览到相关的实时流，然后播放器将获取元数据，并知道接下来要播放的视频片段。
5. 同时，使用者（通过WebRTC）连接到其他使用者
6. 然后，播放器直接从服务器或对等方下载相关块。

遵循这样的模型，取决于实时流的比特率和观看者的协作上行链路，可以节省多达90％的服务器带宽。

免责声明：作者在Peer5工作

我的大师致力于使用WebRTC开发混合的cdn / p2p实时流协议。我已经在http://bem.tv上发布了我的第一个结果

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

Angel Genchev的答案似乎是正确的，但是，有一种理论上的体系结构，它允许通过WebRTC进行低延迟广播。想象B（广播者）流向A1（与会者1）。然后，A2（与会者2）连接。代替从B流到A2，A1开始将视频从B接收到A2。如果A1断开连接，则A2开始从B接收。

如果没有延迟和连接超时，则该体系结构可以工作。因此，从理论上讲这是正确的，但实际上却不正确。

目前，我正在使用服务器端解决方案。

市场上有一些WebRTC可扩展解决方案可用的解决方案。它们提供了低延迟，可扩展的webrtc流。这是一些样品。 Janus，Jitsi，Wowza，Red5pro，蚂蚁媒体服务器

我是Ant Media Server的开发人员，我们同时提供社区和企业版，包括android和iOS SDK。让我们知道我们是否可以以某种方式帮助您。

您正在描述使用WebRTC的一对多需求。WebRTC专为点对点流而设计，但是有些配置可让您从WebRTC的低延迟中受益，同时向许多观众提供视频。

诀窍是不要让每个观看者负担流媒体客户端的费用，就像您提到的那样，拥有一个“中继”媒体服务器。您可以自己构建它，但老实说，最好的解决方案通常是使用Wowza的WebRTC Streaming产品之类的东西。

要从电话中高效地进行流传输，可以使用Wowza的GoCoder SDK，但以我的经验，像StreamGears这样的更高级的SDK 效果最好。

我正在使用Kurento Media Server开发WebRTC广播系统。Kurento支持多种流协议，例如RTSP，WebRTC，HLS。它在实时和缩放方面也能很好地工作。

因此，Kurento不支持现在在Youtube或Twitch中使用的RTMP。我的问题之一是与此同时发生的用户数量。

希望对您有所帮助。

由于peer1只有调用getUserMedia（）的对等方，即peer1创建一个房间。

1. 因此，peer1捕获媒体并开始播放。
2. peer2加入会议室并从peer1获取流（数据），还打开名为“ peer2-connection”的并行连接
3. 当peer3加入会议室并从peer2获取流（数据）时，还打开名为“ peer3-connection”的并行连接，依此类推。

随着许多对等方彼此连接，此过程持续进行。

因此，通过这种方式，可以在无限制的用户上传输单个广播，而不会出现带宽/ CPU使用率问题。

最后，以上所有内容都是Link的参考。