130

问题：

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 的想法？

笔记

根据最终客户糟糕的 UX，Flash 无法满足我的需求。

解决方案（不是真的）

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

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

建议

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

9 回答 9

74

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

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

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

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

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

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

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

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

玩得开心！希望我有所帮助。

于 2015-02-21T12:40:19.227 回答
11

正如@MuazKhan 上面提到的：

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

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

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

该模块简单地初始化 socket.io 并将其配置为单个广播可以中继给无限的用户，而不会出现任何带宽/CPU 使用问题。一切都是点对点发生的！

在此处输入图像描述

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

于 2015-05-26T10:36:34.503 回答
7

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

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

于 2015-02-13T16:07:38.630 回答
6

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

于 2013-11-17T23:52:23.123 回答
5

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

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

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

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

免责声明：作者在Peer5工作

于 2014-03-17T13:56:02.780 回答
5

我的硕士专注于使用 WebRTC 开发混合 cdn/p2p 直播流协议。我已经在http://bem.tv上发布了我的第一个结果

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

于 2014-05-17T17:15:59.667 回答
2

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

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

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

于 2013-11-20T16:18:18.717 回答
2

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

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

希望它有所帮助。

于 2019-02-06T03:26:07.777 回答
1

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

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

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

于 2018-11-27T21:16:58.927 回答