WebRTC - 可扩展的实时流广播/组播

javascript video webrtc scalability broadcast

2022-08-30 04:30:40

问题：

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

笔记

Flash无法满足我的需求，因为最终客户的用户体验很差。

解决方案（不是真的）

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

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

建议

通过调整音频和视频编解码器来降低CPU /带宽;
获取媒体服务器。

答案 1

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

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

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

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

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

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

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

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

玩得愉快！希望我有帮助。

答案 2

如上所述@MuazKhan：

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

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

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

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

enter image description here

这绝对应该是可以完成的。
其他人也能够实现这一目标：http://www.streamroot.io/