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

WebRTC - scalable live stream broadcasting / multicasting

提问by igorpavlov

PROBLEM:

问题：

WebRTC gives us peer-to-peer video/audio connections. It is perfect for p2p calls, hangouts. But what about broadcasting (one-to-many, for example, 1-to-10000)?

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

Lets say we have a broadcaster "B" and two attendees "A1", "A2". Of course it seems to be solvable: we just connect B with A1 and then B with A2. So B sends video/audio stream directly to A1 and another stream to A2. B sends streams twice.

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

Now lets imagine there are 10000 attendees: A1, A2, ..., A10000. It means B must send 10000 streams. Each stream is ~40KB/s which means B needs 400MB/s outgoing internet speed to maintain this broadcast. Unacceptable.

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

ORIGINAL QUESTION (OBSOLETE)

原始问题（已过时）

Is it possible somehow to solve this, so B sends only one stream on some server and attendees just pull this stream from this server? Yes, this means the outgoing speed on this server must be high, but I can maintain it.

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

Or maybe this means ruining WebRTC idea?

或者这可能意味着破坏 WebRTC 的想法？

NOTES

笔记

Flash is not working for my needs as per poor UX for end customers.

由于最终客户的用户体验不佳，Flash 无法满足我的需求。

SOLUTION (NOT REALLY)

解决方案（不是真的）

26.05.2015 - There is no such a solution for scalable broadcasting for WebRTC at the moment, where you do not use media-servers at all. There are server-side solutions as well as hybrid (p2p + server-side depending on different conditions) on the market.

26.05.2015 - 目前没有这样的 WebRTC 可扩展广播解决方案，您根本不使用媒体服务器。市场上有服务器端解决方案，也有混合（p2p+服务器端，视不同情况而定）。

There are some promising techs though like https://github.com/muaz-khan/WebRTC-Scalable-Broadcastbut they need to answer those possible issues: latency, overall network connection stability, scalability formula (they are not infinite-scalable probably).

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

SUGGESTIONS

建议

1. Decrease CPU/Bandwidth by tweaking both audio and video codecs;
2. Get a media server.

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

回答by nschoe

As it was pretty much covered here, what you are trying to do here is not possible with plain, old-fashionned WebRTC (strictly peer-to-peer). Because as it was said earlier, WebRTC connections renegotiate encryption keys to encrypt data, for each session. So your broadcaster (B) will indeed need to upload its stream as many times as there are attendees.

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

However, there is a quite simple solution, which works very well: I have tested it, it is called a WebRTC gateway. Janusis a good example. It is completely open source (github repo here).

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

This works as follows: your broadcaster contacts the gateway (Janus) which speaks WebRTC. So there is a key negotiation: B transmits securely (encrypted streams) to Janus.

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

Now, when attendees connect, they connect to Janus, again: WebRTC negotiation, secured keys, etc. From now on, Janus will emit back the streams to each attendees.

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

This works well because the broadcaster (B) only uploads its stream once, to Janus. Now Janus decodes the data using its own key and have access to the raw data (that it, RTP packets) and can emit back those packets to each attendee (Janus takes care of encryption for you). And since you put Janus on a server, it has a great upload bandwidth, so you will be able to stream to many peer.

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

So yes, it doesinvolve a server, but that server speaks WebRTC, and you "own" it: you implement the Janus part so you don't have to worry about data corruption or man in the middle. Well unless your server is compromised, of course. But there is so much you can do.

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

To show you how easy it is to use, in Janus, you have a function called incoming_rtp()(and incoming_rtcp()) that you can call, which gives you a pointer to the rt(c)p packets. You can then send it to each attendee (they are stored in sessionsthat Janus makes very easy to use). Look here for one implementation of the incoming_rtp()function, a couple of lines belowyou can see how to transmit the packets to all attendees and hereyou can see the actual function to relay an rtp packet.

为了向您展示它的易用性，在 Janus 中，您有一个名为incoming_rtp()(and incoming_rtcp())的函数，您可以调用它，它为您提供一个指向 rt(c)p 数据包的指针。然后，您可以将其发送给每位与会者（它们存储在sessionsJanus 中，非常易于使用）。在这里寻找一个实现的incoming_rtp()功能，一对夫妇低于行的，你可以看到如何将数据包发送给所有与会者，并在这里你可以看到实际的功能中继的RTP包。

It all works pretty well, the documentation is fairly easy to read and understand. I suggest you start with the "echotest" example, it is the simplest and you can understand the inner workings of Janus. I suggest you edit the echo test file to make your own, because there is a lot of redundant code to write, so you might as well start from a complete file.

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

Have fun! Hope I helped.

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

回答by rubo77

As @MuazKhan noted above:

正如@MuazKhan 上面提到的：

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

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

works in chrome, and no audio-broadcast yet, but it seems to be a 1st Solution.

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

A Scalable WebRTC peer-to-peer broadcasting demo.

This module simply initializes socket.io and configures it in a way that single broadcast can be relayed over unlimited users without any bandwidth/CPU usage issues. Everything happens peer-to-peer!

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

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

This should definitely be possible to complete.
Others are also able to achieve this: http://www.streamroot.io/

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

回答by Tom

AFAIK the only current implementation of this that is relevant and mature is Adobe Flash Player, which has supported p2p multicast for peer to peer video broadcasting since version 10.1.

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

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

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

回答by Angel Genchev

"Scalable" broadcasting is not possible on the Internet, because the IP UDP multicasting is not allowed there. But in theory it's possible on a LAN.
The problem with Websockets is that you don't have access to RAW UDP by design and it won't be allowed.
The problem with WebRTC is that it's data channels use a form of SRTP, where each session has own encryptionkey. So unless somebody "invents" or an API allows a way to shareone session key between all clients, the multicast is useless.

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

回答by shacharz

There is the solution of peer-assisted delivery, meaning the approach is hybrid. Both server and peers help distribute the resource. That's the approach peer5.comand peercdn.comhave taken.

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

If we're talking specifically about live broadcast it'll look something like this:

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

1. Broadcaster sends the live video to a server.
2. The server saves the video (usually also transcodes it to all the relevant formats).
3. A metadata about this live stream is being created, compatible with HLS or HDS or MPEG_DASH
4. Consumers browse to the relevant live stream there the player gets the metadata and knows which chunks of the video to get next.
5. At the same time the consumer is being connected to other consumers (via WebRTC)
6. Then the player downloads the relevant chunk either directly from the server or from peers.

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

Following such a model can save up to ~90% of the server's bandwidth depending on bitrate of the live stream and the collaborative uplink of the viewers.

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

disclaimer: the author is working at Peer5

免责声明：作者在 Peer5 工作

回答by flavioribeiro

My masters is focused on the development of a hybrid cdn/p2p live streaming protocol using WebRTC. I've published my first results at http://bem.tv

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

Everything is open source and I'm seeking for contributors! :-)

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

回答by igorpavlov

The answer from Angel Genchev seems to be correct, however, there is a theoretical architecture, that allows low-latency broadcasting via WebRTC. Imagine B (broadcaster) streams to A1 (attendee 1). Then A2 (attendee 2) connects. Instead of streaming from B to A2, A1 starts streaming video being received from B to A2. If A1 disconnects then A2 starts receiving from B.

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

This architecture could work if there are no latencies and connection timeouts. So theoretically it is right, but not practically.

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

At the moment I am using server side solution.

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

回答by faraway

There are some solutions available in the market for WebRTC scalable solution. They provide low latency, scalable webrtc streaming. Here are some samples. Janus, Jitsi, Wowza, Red5pro, Ant Media Server

市场上有一些解决方案可用于 WebRTC 可扩展解决方案。它们提供低延迟、可扩展的 webrtc 流媒体。这里有一些示例。 Janus, Jitsi, Wowza, Red5pro, Ant Media Server

I am developer for Ant Media Server, we provide both community and enterprise edition including android and iOS SDK as well. Let us know if we can help you somehow.

我是Ant Media Server 的开发人员，我们提供社区版和企业版，包括 android 和 iOS SDK。如果我们能以某种方式帮助您，请告诉我们。

回答by videoking

You are describing using WebRTC with a one-to-many requirement. WebRTC is designed for peer-to-peer streaming, however there are configurations that will let you benefit from the low latency of WebRTC while delivering video to many viewers.

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

The trick is to not tax the streaming client with every viewer and, like you mentioned, have a "relay" media server. You can build this yourself but honestly the best solution is often to use something like Wowza's WebRTC Streaming product.

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

To stream efficiently from a phone you can use Wowza's GoCoder SDK but in my experience a more advanced SDK like StreamGearsworks best.

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

回答by imalice

I'm developing WebRTC broadcasting system using the Kurento Media Server. Kurento Supports several kinds of streaming protocol such as RTSP, WebRTC, HLS. It works as well in term of real-time and scaling.

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

Hence, Kurento doesn't support RTMP which is used in Youtube or Twitch now. One of the problem with me is the number of user concurrent with this.

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

Hope it help.

希望有帮助。