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，但他们需要回答这些可能的问题：延迟，整体网络连接稳定性，可扩展性公式（它们可能不是无限可扩展的）。

SUGGESTIONS

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

Answer 1

由于这里已经涵盖了很多内容，因此无法使用简单，老式的WebRTC（严格的点对点）来实现此处的功能。因为如前所述，WebRTC连接重新协商加密密钥以加密每个会话的数据。因此，您的广播公司（B）确实需要像参加者一样多次上传其流。

然而，有一个非常简单的解决方案，它运行得很好：我测试过它，它被称为WebRTC网关。 Janus就是一个很好的例子。它是完全开源的（github repo here）。

此操作如下：您的广播公司联系网关（Janus），它说WebRTC 。所以有一个关键的协商：B安全地（加密流）传输给Janus。

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

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

是的，它确实涉及服务器，但该服务器会说WebRTC，而您自己也会＃34;它：你实现了Janus部分，所以你不必担心数据损坏或中间人。当然，除非您的服务器受到损害。但是你可以做很多事情。

为了向您展示使用它是多么容易，在Janus中，您可以调用一个名为incoming_rtp()（和incoming_rtcp()）的函数，它为您提供指向rt的指针（c） p包。然后，您可以将其发送给每个与会者（它们存储在Janus非常容易使用的sessions中）。 Look here for one implementation of the incoming_rtp() function，a couple of lines below您可以看到如何将数据包传输给所有与会者，here您可以看到中继rtp数据包的实际功能。

一切运作良好，文档相当容易阅读和理解。我建议你从＆＃34; echotest＆＃34;开始例如，它是最简单的，你可以理解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

发布了我的第一个结果

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

Answer 7

Angel Genchev的答案似乎是正确的，然而，有一种理论架构，允许通过WebRTC进行低延迟广播。想象一下B（广播公司）流到A1（与会者1）。然后A2（与会者2）连接。 A1开始将从B接收的视频流传输到A2，而不是从B流式传输到A2。如果A1断开连接，则A2开始从B接收。

如果没有延迟和连接超时，此架构可以正常工作。所以理论上它是正确的，但不是实际的。

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

Answer 8

市场上有一些针对WebRTC可扩展解决方案的解决方案。 它们提供低延迟，可扩展的webrtc流。这是一些样品。 Janus，Jitsi，Wowza，Red5pro，Ant Media Server

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

Answer 9

存在针对此问题的几种解决方案。它提供了低延迟和超低延迟。

选中此medium post

要获得可扩展的超低延迟，您可以尝试ant media server

Answer 10

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

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

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

因此，一次广播可以在无限的用户上传输，而不会出现带宽/ CPU使用率问题。

最后，以上所有内容均来自Link的引用。

Answer 11

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

诀窍是不向每个查看者收费，并且像您提到的那样，拥有“中继”媒体服务器。您可以自己构建它，但老实说，最好的解决方案通常是使用Wowza的WebRTC Streaming product之类的东西。

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

Answer 12

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

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

希望有帮助。

Answer 13

我正在开发Relay版本的WebRTC，但不确定是否可以运行。我的测试仅针对一个用户Johnny，并查看其他用户是否可以relayed观看该流。

1. 我们打开了两个浏览器窗口。第一个是用户Johnny，第二个是特殊用户Relay
2. 在显示中，您将有一个local和一个remote视频元素用于测试。
3. 开始浏览时，连接到Hub的用户将自动显示在浏览器窗口中。
4. 在用户Relay的第一个窗口中单击，该用户将显示在第一个浏览器窗口的remote视频元素中，Johnny将显示在remote中第二个浏览器窗口的窗口。
5. 现在有了一个大技巧，所有其他想要连接到Johnny的用户都必须连接到特殊用户remote的{​​{1}}窗口。此示例是一个用户使用的，但是relay窗口可以具有更多窗口（RTCPeerConnections），以供更多用户连接。
6. relay浏览器窗口将成为其他用户的服务器。所有用户都连接到relay浏览器窗口。将为每个连接的用户创建RTCPeerConnections。

在我的示例中，我使用relay元素对其进行可视化，但是在<video>浏览器窗口中，RTCPeerConnections应该足够。

这是想法逻辑还是我缺少什么？