一个字回答: 要
这是我这个星期经常被问到的问题答案也很简单是的, 需要
接着我收到了一个没有预料到的提问:
为什么需要?
这有点让我措手不及倒不是因为我不知道答案而是因为我不知道如何用简短的文字来回答他我想这也不是一个简单的问题
简单的答案是资源的限制, 以及我们不控制大部分这些资源的事实
硬性上限
无论何时我们想要将两个浏览器使用流直接连接, 都需要创建并使用对等连接
Chrome 65 版本包含了用于垃圾收集目的的上限 Chrome 不允许超过 500 个并发对等连接同时存在
500 是一个非常大的数字了如果你准备使用多余 10 个的并发对等连接, 那么你应该是知道自己在做什么的人之一 (并且不需要本篇文章的帮助) 对于所有我能记得参与过的用例来说, 超过 50 的基本上都是一个坏主意
你需要认清楚资源是有限的免费并在浏览器中实施并不意味着不会产生任何相关费用, 或者不需要在实现过程中出人出力
比特率, 速度以及反馈
这应该是你无法使用 webRTC 或者任何其他技术进行广播的主要原因了
我们正在触碰的是 WebRTC 中充满挑战的部分媒体处理很难而实时媒体处理更难
假设我们想以低 VGA 分辨率广播一个视频我们已经检查并确定了 500kbps 的比特率可以满足我们的需求
如果我们向 10 个人播放我们的数据流, 会发生什么?
将我们的数据流广播到 10 个人, 需要 5Mbps 的上行链路比特率
如果我们使用的是 ADSL 连接, 那么我们只有 1-3Mbps 的上行链路, 所以我们将无法向我们的 10 个观众广播该流
大部分情况下, 我们无法控制广播者的目标是通过 ADSL? 还是无线 WiFi? 还是连接不畅的 3G 网络? 当我们开始处理广播时, 我们需要做出这些假设
这是关于 10 个观众的那如果我们要面对的是 100 个观众? 1000 个? 或者 100 万个?
使用媒体服务器, 我们要决定网络的连接性, 服务器的机器类型等等我们可以决定把媒体服务器级联起来以扩大我们的广播规模我们对这种情况会有更多的控制
所以广播 WebRTC 媒体流需要媒体服务器
发送端一致性
这点在网格状群组通话中很常见, 但是在广播中也同样重要
当我们将 WebRTC 用于广播类型的服务时, 很多决定最终都会发生在媒体服务器中如果观众所处的网络环境不好, 则会导致丢包, 报告给媒体服务器那么媒体服务器在这种情况下会做什么呢?
虽然没有一个简单的答案来回答这个问题, 但是其中包括了这些选项:
要求广播者发送一个新的 I - 帧, 这会影响所有的观众, 并在不就的将来增加带宽使用
要求广播者降低比特率和媒体质量以适应丢包, 这不仅仅会影响不良网络上的观众, 也会影响到所有收看者
忽略丢包的问题, 牺牲部分观众给其他人提供更好的服务
使用同播或 SVC, 并将观众转移到较低媒体质量的较低层, 而不会影响其他用户
你不能在浏览器中完成大部分操作浏览器倾向于使用相同的单一编码流发送给所有其他用户, 并且在多用户方面正确估计带宽做得不好这不是设计成或者实施成这样的
你需要一个媒体服务器
在大多数情况下, 某些时候你需要一个媒体服务器
如果你正在广播, 那么媒体服务器是强制性的谷歌不提供这样的美俄费服务, 甚至不提供针对该用例的开源代码
这不意味着媒体服务器不能拥有只是需要你更加努力
来源: https://juejin.im/post/5a9514c9f265da4e8837d7c6