WebRTC - 可扩展的直播流广播/多播 [英] WebRTC - scalable live stream broadcasting / multicasting
问题描述
问题:
WebRTC 为我们提供点对点视频/音频连接.它非常适合 p2p 通话、环聊.但是广播呢(一对多，例如，1-to-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 与 A1 连接，然后将 B 与 A2 连接.因此 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 存储库).
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 数据包的指针.然后，您可以将其发送给每位与会者(它们存储在 sessions 中，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.
一切都很好，文档相当容易阅读和理解.我建议您从echotest"示例开始，它是最简单的，您可以了解 Janus 的内部工作原理.建议你编辑一下echo test文件，制作自己的，因为有很多多余的代码要写，所以不妨从一个完整的文件开始.
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屋！
