视频会议系统EasyRTC常见的几种架构方式及应用场景:MCU/SFU、视频会议、应急指挥、即时通信

我们这里常说的RTC可以理解为WebRTC技术,因为WebRTC技术是目前使用最广泛的即时通信技术,虽然在早期我们提到WebRTC、提到视频通话就会想到P2P的方式,但实际的视频通话方式背后的逻辑有很多种,p2p并不能解决所有的网络通信问题,视频通话会采用多种架构相结合的方式,保障用户视频通话的接通率。

视频会议系统EasyRTC常见的几种架构方式及应用场景:MCU/SFU、视频会议、应急指挥、即时通信_第1张图片

WebRTC虽然是一项主要使用p2p的实时通讯技术,本应该是无中心化节点的,但是在一些大型多人通讯场景,如果都使用端对端直连,端上会遇到很多带宽和性能的问题,所以就有了下图的三种架构。

视频会议系统EasyRTC常见的几种架构方式及应用场景:MCU/SFU、视频会议、应急指挥、即时通信_第2张图片

一、Mesh架构

即:每个端都与其它端互连。以上图最左侧为例,5个浏览器,二二建立p2p连接,每个浏览器与其它4个建立连接,总共需要10个连接。如果每条连接占用1M带宽,则每个端上行需要4M,下行带宽也要4M,总共带宽消耗20M。而且除了带宽问题,每个浏览器上还要有音视频“编码/解码”,CPU使用率也是问题,一般这种架构只能支持4-6人左右,不过优点也很明显,没有中心节点,实现很简单。

二、MCU (MultiPoint Control Unit)

这是一种传统的中心化架构(上图中间部分),每个浏览器仅与中心的MCU服务器连接,MCU服务器负责所有的视频编码、转码、解码、混合等复杂逻辑,每个浏览器只要1个连接,整个应用仅消耗5个连接,带宽占用(包括上行、下行)共10M,浏览器端的压力要小很多,可以支持更多的人同时音视频通讯,比较适合多人视频会议。但是MCU服务器的压力较大,需要较高的配置。

视频会议系统EasyRTC常见的几种架构方式及应用场景:MCU/SFU、视频会议、应急指挥、即时通信_第3张图片

三、SFU(Selective Forwarding Unit)

上图右侧部分,虽然看起来和MCU区别不大,但其实在思路上大有不同,仍然有中心节点服务器,但是中心节点只负责转发,不做太重的处理,所以服务器的压力会低很多,配置也不象MUC要求那么高。但是每个端需要建立一个连接用于上传自己的视频,同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5,消耗的带宽也是最大的,如果每个连接1M带宽,总共需要25M带宽,它的典型场景是1对N的视频互动。

视频会议系统EasyRTC常见的几种架构方式及应用场景:MCU/SFU、视频会议、应急指挥、即时通信_第4张图片

目前,随着5G技术的推广,可以预见带宽越来越不是问题,所以SFU在未来,可能会更有优势。

建议:如果规模不大(5人以下) Mesh框架就够用了,毕竟实现简单;如果50人以下,且带宽有限,选择MCU比较适合;如果规模更大,且带宽良好,SFU相对更适合。

在TSINGSEE青犀视频产品体系里,我们也在不断对MCU、SFU的使用场景进行研究和拓展,在许多的应急指挥场景中,我们不仅需要即时的通信,而且需要事后的回溯,所以MCU的录像功能必不可少。

当我们在人数众多的集群调度和大班课教学时,我们又需要对感兴趣的视频源选择接听,而对大部分的非相关人员视频屏蔽,在多方连线场景中,我们需要选择性了解现场情况,放大单路视频,所以这些情况,MCU和SFU的选择不是绝对的,而将会是相互结合的。

视频会议系统EasyRTC常见的几种架构方式及应用场景:MCU/SFU、视频会议、应急指挥、即时通信_第5张图片

在WebRTC方面,TSINGSEE青犀视频团队已经逐步拓展了EasyRTC视频会议与EasyRTS应急指挥系统,EasyRTC具有MCU和SFU两个版本,EasyRTS则采用SFU接入与后端视频处理的方式,完美地解决了视频即时通信的各种应用场景需求。

视频相关解决方案均可访问TSINGSEE青犀视频官网,详细了解系统效果:www.tsingsee.com

你可能感兴趣的:(EasyRTC,TSINGSEE青犀视频,视频会议系统,多人视频,mesh,MCU)