WebRTC - 可扩展的直播流广播/多播 [英] WebRTC - scalable live stream broadcasting / multicasting
问题描述
问题：
WebRTC为我们提供点对点视频/音频连接。它非常适合p2p通话，环聊。但是广播怎么样（一对多，例如，1到10000）？
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)?
假设我们有一个广播员B和两个与会者A1，A2。当然它似乎是可以解决的：我们只用B连接B，然后用A2连接B.因此B将视频/音频流直接发送到A1，将另一个流发送到A2。 B发送两次流。
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.
现在假设有10000名与会者：A1，A2，...，A10000。这意味着B必须发送10000个流。每个流约为40KB / s，这意味着B需要400MB / s的外出网速来维持这种广播。不可接受。
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.
原始问题（已废除）
是否有可能以某种方式解决这个，所以B只在一些服务器上发送一个流，参与者只是从这个服务器中提取这个流？是的，这意味着此服务器上的传出速度必须很高，但我可以保持它。
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.
或许这意味着毁掉WebRTC的想法？
Or maybe this means ruining WebRTC idea?
注意
根据最终客户的不良用户体验，Flash无法满足我的需求。
Flash is not working for my needs as per poor UX for end customers.
解决方案（不是真的）
26.05.2015 - 目前没有针对WebRTC的可扩展广播的解决方案，您根本不使用媒体服务器。市场上有服务器端解决方案以及混合（p2p +服务器端，具体取决于不同的条件）。
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.
有一些有前途的技术，但像 https://github.com/muaz-khan/WebRTC-Scalable-Broadcast 但他们需要回答这些可能的问题：延迟，整体网络连接稳定性，可扩展性公式（它们可能不是无限可扩展的）。
There are some promising techs though like https://github.com/muaz-khan/WebRTC-Scalable-Broadcast but they need to answer those possible issues: latency, overall network connection stability, scalability formula (they are not infinite-scalable probably).
建议
- 通过调整音频和视频编解码器来降低CPU /带宽;
- 获取媒体服务器。
推荐答案
因为这里有很多内容，你在这里尝试做什么是不可能的朴素的，老式的WebRTC（严格的点对点）。因为如前所述，WebRTC连接重新协商加密密钥以加密每个会话的数据。因此，您的广播公司（B）确实需要像参加者一样多次上传其流。
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网关。 Janus 就是一个很好的例子。它是完全开源的（ github repo here ）。
However, there is a quite simple solution, which works very well: I have tested it, it is called a WebRTC gateway. Janus is a good example. It is completely open source (github repo here).
此工作方式如下：您的广播公司联系网关（Janus），它说WebRTC 。所以有一个关键的协商：B安全地（加密流）传输给Janus。
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.
现在，当与会者连接时，他们再次连接到Janus：WebRTC协商，安全密钥等。从现在开始，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.
这很有效，因为广播公司（B）只将其流一次上传到Janus。现在，Janus使用自己的密钥对数据进行解码，并可以访问原始数据（即RTP数据包），并可以将这些数据包发回给每个与会者（Janus负责为您加密）。由于您将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.
所以是的，确实涉及服务器，但是该服务器会说WebRTC，而你拥有它：你实现了Janus部分所以你不必担心数据损坏或中间人。当然，除非您的服务器受到损害。但是你可以做很多事情。
So yes, it does involve 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.
为了向您展示它的使用方式，在Janus中，您有一个名为 incoming_rtp（）的函数（和 incoming_rtcp（））你可以调用它，它给你一个指向rt（c）p数据包的指针。然后，您可以将其发送给每个与会者（它们存储在会话中，Janus非常容易使用）。 在此处查看 incoming_rtp（）的一个实现功能，以下几行您可以看到如何将数据包传输给所有与会者并此处你可以看到转发rtp数据包的实际功能。
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 sessions that Janus makes very easy to use). Look here for one implementation of the incoming_rtp() function, a couple of lines below you can see how to transmit the packets to all attendees and here you can see the actual function to relay an rtp packet.
这一切都运行得很好，文档相当容易阅读和理解。我建议你从回声的例子开始，它是最简单的，你可以理解Janus的内部运作。我建议你编辑echo测试文件来制作你自己的，因为有很多冗余的代码要编写，所以你不妨从一个完整的文件开始。
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.
玩得开心！希望我帮忙。
Have fun! Hope I helped.
这篇关于WebRTC - 可扩展的直播流广播/多播的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
