webrtc标准定制了web上如何p2p传输实时媒体, 但多人视频并没有规范,同时也是webrtc在企业级解决方案中的一个挑战,webrtc技术视频
会议方案可以归纳为一下几种
1. Mesh solution
这是最简单的方案,其原理就是客户端创建多个one-one的连接,互相relay媒体,这种方案服务器不需要改动,简单,但是客户端占用资源多。
2. Mixer solution
这种方案是传统视频会议解决方案,其核心是中心控制单元MCU负责媒体的编解码,MCU把多路音视频接收,解码,混合后编码,以一路的方式转发给多个客户端,这种方式的好处是客户端无需做任何与多人视频相关改动,客户端与服务器只保持一路媒体,但这种方案增加了MCU的复杂度,通常采用硬件方式做视频编解码。
3. router solution
这种方式是最近几年出现的方案,同时也是h264 svc codec出现后引入,其原理是服务器端只负责转码媒体,而不需要Mixer solution里面的转码过程,这很大程度上提高了服务器并发能力。
方案对比:
以上几种方案实际使用中各有优劣,需要根据实际使用情况选择,
如果你只需要音频会议,同时需要与legacy 设备互通,方案2是不错的选择,如果你的客户端具备很好的性能,带宽环境又很高,同时并发会议的人数有限,则方案1可以考虑,比如四人的视频会议,这种方案服务器端成本最低。
如果你要构建一个大规模的服务,不需要与legcay的设备互通,方案3是个不错的选择。
基于webrtc技术的视频会议方案探讨
原创
©著作权归作者所有:来自51CTO博客作者voipmaker的原创作品,请联系作者获取转载授权,否则将追究法律责任
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
tfs多人签出--禁止多人签出
tfs2013是默认允许多人签出,而我们做项目时是不允许多人签出,因为文件冲突,后面合并时
tfs 多人签出 tfs多人签出 tfs2013 签出 -
KeepAlived 组播请求查看
图文无关什么是状态保存?假设有下述场景:移动端中,用户访问了一个列表页,上拉浏览列表页的过程中,随着滚动高度逐渐增加,数据也将采用触底分页加载的形式逐步增加,列表页浏览到某个位置,用户看到了感兴趣的项目,点击查看其详情,进入详情页,从详情页退回列表页时,需要停留在离开列表页时的浏览位置上类似的数据或场景还有已填写但未提交的表单、管理系统中可切换和可关闭的功能标签等,这类数据随着用户交互逐渐变化或
KeepAlived 组播请求查看 React.js Web前端 Javascript keep-alive