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

问题:

WebRTC 为我们提供点对点的视频/音频连接。它非常适合点对点通话，常去的地方。但是广播(一对多，例如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，但是他们需要解决这些可能的问题: 延迟、整体网络连接稳定性、可伸缩性公式(它们可能不是无限可伸缩的)。

建议

  1. 通过调整音频和视频编解码器来降低 CPU/带宽;
  2. 找个媒体服务器。
53570 次浏览
小开

“可伸缩”广播是不可能在互联网上，因为 IP UDP 多播是不允许的。但理论上，在局域网上是可行的。< br/> Websockets 的问题在于，您在设计上无法访问 RAW UDP，而且也不允许访问。
WebRTC 的问题在于它的数据通道使用 SRTP 形式，其中每个会话都有自己的 加密密钥。因此，除非有人“发明”或 API 允许在所有客户端之间使用一个会话密钥 分享，否则多播是无用的。

小开

Angel Genchev 的答案似乎是正确的，然而，有一个理论架构，允许通过 WebRTC 进行低延迟广播。想象一下 B (广播)流到 A1(与会者1)。然后 A2(与会者2)连接。A1开始从 B 到 A2接收流媒体视频，而不是从 B 到 A2。如果 A1断开连接，那么 A2开始接收 B。

如果没有延迟和连接超时，这种体系结构可以工作。

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

小开

有一种解决方案是同伴协助分娩，这意味着这种方法是混合的。服务器和对等点都有助于分发资源。这就是 Peer5.com和 Peercdn.com所采取的方法。

如果我们特别讨论直播的话，它会是这样的:

  1. 广播员将现场视频发送到服务器。
  2. 服务器保存视频(通常还将其转码为所有相关格式)。
  3. 正在创建关于此实时流的元数据，该元数据与 HLS 或 HDS 或 MPEG _ DASH 兼容
  4. 消费者浏览到相关的实时流，播放器获得元数据，并知道下一个要获得的视频块。
  5. 同时，消费者被连接到其他消费者(通过 WebRTC)
  6. 然后播放器直接从服务器或对等机下载相关块。

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

免责声明: 作者在 Peer5工作

小开

我的硕士学位主要集中在使用 WebRTC 开发一个混合的 cdn/p2p 直播流协议。我已经在 http://bem.tv发表了我的第一个结果

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

小开

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

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

小开

由于这里已经介绍得差不多了，所以您在这里尝试做的事情在普通的、老式的 WebRTC (严格的点对点)上是不可能的。因为如前所述，WebRTC 连接为每个会话重新协商加密密钥以加密数据。因此，你的广播公司(B)确实需要上传它的流，因为有多少与会者。

然而，有一个非常简单的解决方案，它工作得非常好: 我已经测试过了，它被称为 WebRTC 网关。两面神就是一个很好的例子。它是完全开源的(我是 Github Repo)。

工作原理如下: 您的广播电台联系网关(Janus) 说的是 WebRTC。因此，有一个关键的协商: B 传输安全(加密流) Janus。

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

这个工作得很好，因为广播者(B)只上传它的流一次，到 Janus。现在 Janus 使用自己的密钥对数据进行解码，并且可以访问原始数据(即 RTP 数据包) ，并且可以向每个与会者发送这些数据包(Janus 负责加密)。因为你把两面神放在一个服务器上，它有一个伟大的上传带宽，所以你将能够流到许多同行。

所以，是的，它 是的涉及到一个服务器，但是那个服务器使用 WebRTC，并且您“拥有”它: 您实现 Janus 部分，所以您不必担心数据损坏或中间的人。当然，除非你的服务器被入侵了。但你能做的还有很多。

为了向您展示它的易用性，在 Janus 中，您可以调用一个名为 incoming_rtp()(和 incoming_rtcp())的函数，它为您提供一个指向 rt (c) p 数据包的指针。然后您可以将其发送给每个与会者(它们存储在 sessions中，Janus 使其非常易于使用)。在这里查找 incoming_rtp()函数的一个实现、 下面几行你可以看到如何向所有与会者发送数据包，而 给你你可以看到实际的转发 rtp 数据包的功能。

它工作得非常好，文档相当容易阅读和理解。我建议你从“回声测试”的例子开始，这是最简单的，你可以理解两面神的内在工作原理。我建议您编辑 echo 测试文件来创建自己的文件，因为需要编写大量冗余代码，所以您不妨从一个完整的文件开始。

玩得开心，希望我帮上忙了。

小开

正如@MuazKhan 所指出的:

Https://github.com/muaz-khan/webrtc-scalable-broadcast

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

一个可伸缩的 WebRTC 点对点广播演示。

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

enter image description here

这应该是完全有可能完成的。
其他人也可以做到这一点: http://www.streamroot.io/

小开

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

诀窍是不要对每个浏览器都征收流媒体客户端的税，并且像您提到的那样，拥有一个“中继”媒体服务器。您可以自己构建它，但是说实话，最好的解决方案通常是使用 Wowza 的 WebRTC 流媒体产品之类的东西。

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

小开

我正在使用 库伦托媒体服务器开发 WebRTC 广播系统。Kurento 支持多种流协议，如 RTSP、 WebRTC、 HLS。它在实时性和伸缩性方面也很好。

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

希望能有帮助。


提交答案