0

作者:Tsahi Levent-Levi(原文链接

翻译:刘通

原标题:Do I Need a Media Server for a One-to-Many WebRTC Broadcast?

 

一个字回答:要。

broadcast1

这是我这个星期经常被问到的问题。答案也很简单—是的,需要。

接着我收到了一个没有预料到的提问:

为什么需要?

这有点让我措手不及。倒不是因为我不知道答案。而是因为我不知道如何用简短的文字来回答他。我想这也不是一个简单的问题。

简单的答案是资源的限制,以及我们不控制大部分这些资源的事实。

硬性上限

无论何时我们想要将两个浏览器使用流直接连接,都需要创建并使用对等连接。

Chrome 65版本包含了用于垃圾收集目的的上限。Chrome不允许超过500个并发对等连接同时存在。

broadcast2

500是一个非常大的数字了。如果你准备使用多余10个的并发对等连接,那么你应该是知道自己在做什么的人之一(并且不需要本篇文章的帮助)。对于所有我能记得参与过的用例来说,超过50的基本上都是一个坏主意。

你需要认清楚资源是有限的。免费并在浏览器中实施并不意味着不会产生任何相关费用,或者不需要在实现过程中出人出力。

比特率,速度以及反馈

这应该是你无法使用WebRTC或者任何其他技术进行广播的主要原因了。

我们正在触碰的是WebRTC中充满挑战的部分。媒体处理很难。而实时媒体处理更难。

假设我们想以低VGA分辨率广播一个视频。我们已经检查并确定了500kbps的比特率可以满足我们的需求。

如果我们向10个人播放我们的数据流,会发生什么?

broadcast3

将我们的数据流广播到10个人,需要5Mbps的上行链路比特率。

如果我们使用的是ADSL连接,那么我们只有1-3Mbps的上行链路,所以我们将无法向我们的10个观众广播该流。

大部分情况下,我们无法控制广播者的目标。是通过ADSL?还是无线WiFi?还是连接不畅的3G网络?当我们开始处理广播时,我们需要做出这些假设。

这是关于10个观众的。那如果我们要面对的是100个观众?1000个?或者100万个?

使用媒体服务器,我们要决定网络的连接性,服务器的机器类型等等。我们可以决定把媒体服务器级联起来以扩大我们的广播规模。我们对这种情况会有更多的控制。

所以广播WebRTC媒体流需要媒体服务器。

发送端一致性

这点在网格状群组通话中很常见,但是在广播中也同样重要。

当我们将WebRTC用于广播类型的服务时,很多决定最终都会发生在媒体服务器中。如果观众所处的网络环境不好,则会导致丢包,报告给媒体服务器。那么媒体服务器在这种情况下会做什么呢?

broadcast4

虽然没有一个简单的答案来回答这个问题,但是其中包括了这些选项:

# 要求广播者发送一个新的I-帧,这会影响所有的观众,并在不就的将来增加带宽使用。

# 要求广播者降低比特率和媒体质量以适应丢包,这不仅仅会影响不良网络上的观众,也会影响到所有收看者

# 忽略丢包的问题,牺牲部分观众给其他人提供“更好”的服务

# 使用同播或SVC,并将观众转移到较低媒体质量的较低“层”,而不会影响其他用户。

你不能在浏览器中完成大部分操作。浏览器倾向于使用相同的单一编码流发送给所有其他用户,并且在多用户方面正确估计带宽做得不好。这不是设计成或者实施成这样的。

你需要一个媒体服务器

在大多数情况下,某些时候你需要一个媒体服务器。

如果你正在广播,那么媒体服务器是强制性的。谷歌不提供这样的美俄费服务,甚至不提供针对该用例的开源代码。

这不意味着媒体服务器不能拥有—只是需要你更加努力。





加入WebRTC技术交流群,免费获得学习资料,交流经验
QQ 2 群:929077590
q群
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.