【转】WebRTC多人音视频解决方案
文章目录
- 1. 引言
- 2. 解决方案
- 2.1 Mesh解决方案
- 2.2 Mixer解决方案
- 2.3 Router解决方案
- 2.4 三个解决方案的流量对比
- 3. 应该使用哪种架构?
- 4. 参考资料
1. 引言
众所周知,WebRTC非常适合点对点(即一对一)的音视频会话。然而,当我们的客户要求超越一对一,即一对多、多对一设置多对多的解决方案或者服务,那么问题就来了:“我们应该采用什么样的架构?” 。简单的呢有人会考虑copy多个p2p就完成了多人之间的会话,可并没有考虑到到来的问题:cpu、内存、尤其是流量问题;传统的解决方案是MCU服务器,利用服务器硬件的能力去mix音视频,然后传给各个参与者,这能到达预想的,这个亦能到达我们的需求;使用基于网状拓扑结构的结构可能是前两者的折中之选。
尽管能实现WebRTC多人音视频的方案,该技术的最流行的用途不局限于多方视频会议场景。不要以为只是传统的音视频会议室,更多的情况包括:智能硬件、ipcamera、在线课堂,实时直播等。在每一种情况下,服务器的能力是能够从多个源的媒体流分发到多个客户端。所以…如果你是一个服务供应商如何才能在实现支持WebRTC的多方拓扑结构?
有几种不同的架构根据您的要求,可能是合适的。这些架构基本上他们围绕二点:
- 集中VS对等网络(P2P)
- 混合VS路由。
在这里介绍最流行的解决方案。如果你需要去深入到协议的影响和实施细则的架构,你可以找到所有的相关信息,RTP拓扑IETF文档。
2. 解决方案
2.1 Mesh解决方案
Mesh方法是最简单的解决方案。因为它不需要假设任何服务器,而且直接使用成熟的WebRTC传输方案。该体系结构基于从每一个发送者创建多个一对一的数据流到每一个接收端。
即使它看起来像一个低效的解决方案,在实践中是非常有效的,并且延迟最低,每个接收端都会根据实际情况产生不同的比特率。
唯一的问题是,这种解决方案需要大量的上行带宽将媒体流同时发送至所有目的地,现有的设备实现所需的CPU功率会显著上升。
2.2 Mixer解决方案
Mixer的做法是多人视频会议的传统解决方案,并且使用多年取得了巨大成功。这一成功可以归功于它需要客户端更少消耗这一事实。该架构基于具有中心点保持与每个参与者一对一的流的特性。中心元件接收并混合每个传入的音频流和视频流,以合成一个单一的流出到每一个参加者。在视频会议行业对于这些集中元件的一个常见术语是多点控制单元(MCU)。在实践中,使用一个MCU的通常是指一个混合器容器。
混频器是供传统设备操作间很好的解决方案。它们还允许全位速率适配,因为混频器可以产生不同的输出流,所以每个接收器有不同的品质。混合器解决方案的另一个优点是它可以利用硬件设备编解码。
主要缺点是在MCU的基础设施成本高。此外,由于混合需要解码和再编码,这引入额外的延迟和质量的损失。最后,转码和组合物可在理论上导致对应用程序的用户界面的弹性较小(尽管有此问题的解决方法)。
2.3 Router解决方案
Router(或中继)的办法使得H.264 SVC基础设施普及,这也正是广泛应用的。该架构基于具有中心点从每个发送器接收一个流并发送出一个流到每一个参与者。这个中心点只做数据包检测和转发,而不是昂贵的编码和实际的媒体的解码。常见术语是SFU。
Router提供一个便宜的可扩展的多方传输,具有较好的延迟性、与传统的mixer解决方案相比没有质量劣化。
这种方案非常适合大并发的事实会议和直播。目前较成熟的服务提供商就是声网。
2.4 三个解决方案的流量对比
3. 应该使用哪种架构?
这个就需要根据自己的项目的需要了。其实,商业解决方案,包括上述所有方案,往往需要根据客户的实际应用场景选择对于的方法。不过,也有经验,你可以使用一些通用规则。
如果您仅是提供P2P音视频传输的服务,Mesh架构可能是最适合你的。另外,如果基础设施的成本不是问题,并且参与者具有异构连接,这可以是一个很好的解决方案。
假设你提供企业级服务,且有较好的宽带和高效的硬件(即一个企业内部服务),参加人数是有限的,那么你非常适合Mixer方案。
一般来说,如果你提供大规模服务的,应优先考虑到Router的方法。Router传输接近把情报在网络的边界,构建最终用户应用程序时,以达到更好的可扩展性和灵活性的网络的范例。
4. 参考资料
- 基于webrtc多人音视频的研究
https://blog.csdn.net/gupar/article/details/53101435
【转】WebRTC多人音视频解决方案相关推荐
- 基于webrtc多人音视频的研究(一)
所周知,WebRTC非常适合点对点(即一对一)的音视频会话.然而,当我们的客户要求超越一对一,即一对多.多对一设置多对多的解决方案或者服务,那么问题就来了:"我们应该采用什么样的架构?&qu ...
- iOS WebRTC多人音视频建立的流程
前言 本文主要以"代码是最好的注释"为基点,介绍在处理iOS端多人音视频的建立流程. 在看本篇前建议先了解一下多人音视频通讯现在的常用架构,参考<WebRTC多人音视频聊天架 ...
- WebRTC多人音视频聊天架构及实战
三种模式 简单介绍一下基于 WebRTC 的多人通信的几种架构模式. 1.Mesh 架构 我们之前写过几个 1 v 1 的栗子,它们的连接模式如下: 这是典型的端到端对等连接,所以当我们要实现多人视频 ...
- IBM Cloud:裸金属服务器+多云策略助力音视频解决方案成功出海
点击上方"LiveVideoStack"关注我们 到底什么是公有云.私有云和混合云?疫情给云服务厂商带来了哪些挑战?IBM是如何助力音视频解决方案成功出海的?"后疫情&q ...
- LiveVideoStackCon讲师热身分享 ( 十五 ) —— 教育场景下的实时音视频解决方案
LiveVideoStackCon 2018音视频技术大会是每年的多媒体技术人的盛宴,为了让参会者与大会讲师更多互动交流,我们推出了LiveVideoStackCon讲师热身分享第一季,在每周四晚19 ...
- 【流媒体服务器Mediasoup】多人音视频架构、流媒体的比较、mediasoup介绍 (一)
目录 前言 多人音视频架构 流媒体服务器的比较 Mediasoup流媒体服务器架构及特点 前言 WebRtc有两种含义,其一是Google开源的流媒体实时通讯客户端,主要运用于 ...
- 赶上直播电商、在线教育、小程序直播的风口 腾讯音视频解决方案助力
小暑 发自 凹非寺 量子位 编辑 | 公众号 QbitAI 从18年至今音视频产品市场暴增20倍以上.疫情期间,远程会议.在线课堂等业务井喷带来了音视频流量的急剧增长.腾讯云实时音视频日均通话时长突 ...
- WebRTC 中收集音视频编解码能力
在 WebRTC 中,交互的两端在建立连接过程中,需要通过 ICE 协议,交换各自的音视频编解码能力,如编解码器和编解码器的一些参数配置,并协商出一组配置和参数,用于后续的音视频传输过程. 对于音频, ...
- 美摄 - 助力打造完善的音视频解决方案
随着短视频成为人们竞相追逐的新风口,移动端音视频处理需求与日俱增.如何低成本.高效率地处理音视频,并且最大程度的适应移动互联网的不同应用需求成为至关重要的问题.本次分享以美摄SDK的音视频处理框架为依 ...
最新文章
- gDebugger 3.1.1 原版+破解
- LeetCode-剑指 Offer 04. 二维数组中的查找
- Framelayout
- OpenCASCADE绘制测试线束:布尔运算命令之检查命令
- php左侧,php左侧补零
- 关于私钥加密、公钥加密、签名在生活中的场景
- 2022年电工杯数学建模A题思路
- apk提取加密素材_高效IO之Dex加密(三)
- Marlin关于如何接收Gcode指令的详解
- 三星note10 android q,【极光ROM】-【三星NOTE10/NOTE10+/5G N97XX-9825】-【V5.0 Android-Q-TE9】...
- ansys18安装以后打不开_ansys18.0安装过程及常见问题解决方案【图文】
- 产品经理,该如何做好「自己」这款产品?
- 【内网穿透服务器】使用FRP实现内网穿透,远程访问内网服务器
- HTTP/HTTPS账号密码获取
- 【R语言】沈阳地铁数据处理及站间流量统计——R语言第五次实训
- 黑客喜欢的扫描器盒子
- 字体大宝库:35款时尚的英文简历字体下载
- 从追赶者到竞争者,智能汽车产业“长沙模式”走的什么捷径?
- 交互模型你快跑,双塔要卷过来了
- 编译安装时关于python的报错