WebRTC - 可扩展的直播流广播/多播答案

【问题标题】：WebRTC - scalable live stream broadcasting / multicastingWebRTC - 可扩展的直播流广播/多播
【发布时间】：2013-08-21 13:20:21
【问题描述】：

问题：

WebRTC 为我们提供点对点视频/音频连接。它非常适合 p2p 通话、视频群聊。但是广播（一对多，例如，1 到 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 的想法？

注意事项

根据终端客户糟糕的用户体验，Flash 无法满足我的需求。

解决方案（不是真的）

26.05.2015 - 目前没有这样的 WebRTC 可扩展广播解决方案，您根本不使用媒体服务器。市场上有服务器端解决方案以及混合（p2p + 服务器端，具体取决于不同的条件）。

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

建议

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

【问题讨论】：

“构建可扩展应用程序的唯一方法是使用服务器端解决方案。”这似乎很清楚...... 至于 WebRTC，它从未打算用于大规模广播。为此使用支持多播的东西，或者如果您必须通过 Internet，则使用基于服务器的一对一连接，因为 ISP 不路由多播。
为什么不使用 WebRTC 从客户端到服务器？问题在于分发，因为客户端的连接无法处理它，因此向服务器发送一个蒸汽并从那里流向客户端。带宽会很昂贵，但您无法绕过向每个用户发送单个流或让用户向其他用户发送流。
据我所知，至少有两家公司正在尝试基于 webrtc 的 p2p 视频交付：affovi.com/rtcplayer.html - 主要用于实时视频；和 peer5.com - 主要用于 VOD。
@igorpavlov 你可能想检查一下：github.com/muaz-khan/WebRTC-Scalable-Broadcast 虽然它只适用于 chrome，还没有音频广播。
如果没有某种 MCU，就无法实现这种可扩展性。 WebRTC 被设计为点对点。如果不绝对抨击您的广播公司，您就无法从它进行广播（每个流都有一个唯一的对等连接，实习生是另一个正在编码的流）。至于从点对点中继媒体，这可能是可能的，但是当然，这会为以后添加到流中的每个对等点带来额外的延迟。对于质量和可扩展性，拥有 webrtc MCU 服务器是唯一现实的解决方案。

标签： javascript video webrtc scalability broadcast

【解决方案1】：

因为它在这里几乎涵盖了，所以您在这里尝试做的事情对于简单的老式 WebRTC（严格点对点）是不可能的。因为如前所述，WebRTC 连接会为每个会话重新协商加密密钥以加密数据。因此，您的广播公司 (B) 确实需要上传其流的次数与与会者人数一样多。

但是，有一个非常简单的解决方案，效果很好：我已经测试过了，它被称为 WebRTC 网关。 Janus 就是一个很好的例子。它是完全开源的 (github repo here)。

它的工作原理如下：您的广播公司联系网关 (Janus)说 WebRTC。所以有一个密钥协商：B 安全地传输（加密流）给 Janus。

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

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

所以是的，它确实涉及服务器，但该服务器使用 WebRTC，并且您“拥有”它：您实现了 Janus 部分，因此您不必担心数据损坏或人为在中间。当然，除非您的服务器受到威胁。但是你能做的有很多。

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

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

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

【讨论】：

说这在目前的 Safari（或任何不支持 WebRTC 的浏览器）中不起作用是真的吗？有谁知道混合解决方案，您使用 WebRTC 从浏览器广播到服务器，然后将视频转码为 HLS/HDS（甚至 RTMP）以适应传统广播系统？
@Ben 是的，它不适用于不支持 WebRTC 的浏览器。回到过去（当我写这篇文章时）Safari 显然不支持这一点。但是今天我还没有检查。但我仍然认为他们不支持 WebRTC（虽然有待确认）。至于在混合系统中使用它，这是完全可能的，实际上这是我为我工作的公司所做的；正如你所说，我从浏览器广播到服务器，然后从那里，我构建并插入了一个 GStreamer 管道来对提要进行转码。你也可以这样做！
对jitsi有什么想法吗？ jitisi也一样吗？
@nschoe 这比使用 websocket 做同样的事情更好吗？
您实际上是在解释 SFU（选择性转发单元）的工作原理。你可以用mediasoup做同样的事情

【解决方案2】：

正如上面提到的@MuazKhan：

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

在 chrome 中工作，还没有音频广播，但它似乎是第一个解决方案。

一个可扩展的 WebRTC 点对点广播演示。

这个模块简单地初始化socket.io并以某种方式配置它单个广播可以转发给无限的用户，而无需任何带宽/CPU使用问题。一切都是点对点发生的！

这绝对是可以完成的。
其他人也可以做到这一点：http://www.streamroot.io/

【讨论】：

这些东西对我来说似乎有点过时了。关于这个想法的任何更新或想法？
另外，它是否解决了延迟问题？例如，Peer1 与 Peer5 对话，而 Peer2 最终失去连接。还是这种架构仅适用于 LAN？
另外，Streamroot 和 Peer5 类似吗？

【解决方案3】：

AFAIK 目前唯一相关且成熟的实现是 Adobe Flash Player，它从 10.1 版开始支持点对点视频广播的 p2p 多播。

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

【讨论】：

人们不会扼杀技术。该技术通过提供非常糟糕的用户体验来杀死自己，尤其是在允许使用麦克风/摄像头时。这就是 getusermedia 获胜的地方。
除了糟糕的用户体验，这会是解决方案吗？服务器少？

【解决方案4】：

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

【讨论】：

但是聊天已经在 WebRTC 上工作了，所以每个人都能看到每条消息，所以一对多也应该适用于视频
@rubo77 与通过视频流发送的数据的速率和数量相比，通过短信发送的数据根本算不上什么。因此，聊天可以轻松地同时包含更多用户

【解决方案5】：

有同伴协助交付的解决方案，这意味着该方法是混合的。服务器和对等点都有助于分配资源。这就是peer5.com 和peercdn.com 采用的方法。

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

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

根据实时流的比特率和观众的协作上行链路，遵循这样的模型可以节省高达约 90% 的服务器带宽。

免责声明：作者在 Peer5 工作

【讨论】：

谢谢。我确实了解 peer5，并发现它是一个非常有吸引力的解决方案。然而，这个问题的目的是找到一个绝对无服务器的解决方案（只允许 STUN/TURN）。

【解决方案6】：

我的硕士专注于使用 WebRTC 开发混合 cdn/p2p 直播流协议。我在http://bem.tv

发布了我的第一个结果

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

【讨论】：

你使用任何一种服务器端软件有点像 MCU 吗？
我实际上在使用一些来自 rtcio 的服务器端组件：github.com/rtc-io
看起来你使用他们的组件来发送信号。服务器端视频流怎么样？或者你的解决方案绝对是 P2P？
抱歉，@igorpavlov 回复你的时间太长了，我正在使用 EvoStream 来分割视频，我正在循环视频源并使用 Elemental 编码器指向 EvoStream。
它是一个媒体服务器提供商。更高效？大概。是我要找的吗？没有。

【解决方案7】：

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

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

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

【讨论】：

服务器端解决方案的流速度如何？请分享。
服务器端解决方案是什么意思？你用了什么？这对我的研究会有帮助。请分享。谢谢。
服务器端解决方案是指 Tokbox 的 Opentok。我不做广告，市场上有很多这样的解决方案，但我坚持使用这个。它像媒体服务器一样工作。附言多方通信是什么意思？我不明白。
@igorpavlov 您能否提供提供服务器端 webrtc 的公司列表？我只知道 Flashphoner 和 Opentok。谢谢
我很想知道这是否真的可以扩展。 HUGE 组（1000 多个）的延迟肯定会出现扩展问题，但如果只有 5-10 个，我想它会很好地工作，但如果有人在对等“链”中间，则需要一些花哨的脚部工作“如果它只是一个单一的链，那么离开并重新连接所有后续的对等点将是一个巨大的开销。使用二叉/三叉树结构可能会更好。

【解决方案8】：

我正在使用Kurento Media Server 开发WebRTC 广播系统。 Kurento 支持 RTSP、WebRTC、HLS 等多种流媒体协议。它在实时和缩放方面也很有效。

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

希望对您有所帮助。

【讨论】：

【解决方案9】：

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

诀窍是不要对每个观看者的流媒体客户端征税，并且就像您提到的那样，拥有一个“中继”媒体服务器。您可以自己构建它，但老实说，最好的解决方案通常是使用类似 Wowza 的 WebRTC Streaming product。

要从手机高效流式传输，您可以使用 Wowza 的 GoCoder SDK，但根据我的经验，像 StreamGears 这样更高级的 SDK 效果最好。

【讨论】：

【解决方案10】：

因为 peer1 只是调用 getUserMedia() 的对等方，即 peer1 创建了一个房间。

因此，peer1 捕获媒体并启动房间。
peer2 加入房间并从 peer1 获取流（数据）并打开名为“peer2-connection”的并行连接
当 peer3 加入房间并从 peer2 获取流（数据）并打开名为“peer3-connection”的并行连接等时。

随着许多对等方相互连接，此过程是连续的。

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

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

【讨论】：

已经提到过这种方法，但在现实世界中可能行不通。作为Peer3，我为什么要关心Peer2的带宽性能？当然，如果 Peer2 离开链，Peer3 可能会回退到 Peer1，但这会导致大量的流中断、重新连接等。我在链中越远，我受的苦就越多。所以，是的，可能在 LAN 上工作，但可能就是这样。
并行广播不考虑带宽，如果一旦 peer3 通过 peer2 建立到 peer1 的连接，并且 peer2 回退，peer3 仍然连接到 peer1。
我不确定我是否理解。我实际上并没有提到链接，现在让我参考一下。这个链接github.com/muaz-khan/WebRTC-Scalable-Broadcast 在“它是如何工作的？”中有一张图片。部分。该图像清楚地告诉您，假设 Peer5 断开连接，Peer8、9 和 10 与广播断开连接。他们需要连接到 Peer2 或 Peer6，但这会导致延迟。此外，这个项目既没有贡献者，也没有活动。
这让我觉得这是一个效率较低的 bittorrent 群。