多人音视频架构
Mesh方案
多对多大多进行P2P,在国内P2P直连穿越会出现很大问题。
MCU方案
客户端连接后,对应每个终端都有一个模块进项上传。再将音视频进行拆分解码。进行混屏,压缩编码分别推动给每个终端。
SFU方案
sfu不进行编解码,只是进行转发。只对订阅的终端进行转发。
1V1的通信模型
Licode架构
缺点:太复杂
客户端:
Client APP作为信令通信模块;
发送信令后创建一个房间,先进入SeverApp然后将消息传给Nuve,将消息插入到MQ的消息队列。
Eriza.js:
对房间逻辑配置信令进行传输
WebRTC:
进行通信
服务端:
ErzoController逻辑处理:(服务集)
roomcontroller从MQ中取出消息创建房间。
ErizoAgent:(分布服务)
进行资源分发
Janus SFU架构
缺点:没有使用异步IO事件处理,线程模型主要使用Jlib
1.先访问服务端的HTTPS的服务获取到浏览器要执行的代码。(获取发布的客户端程序)
2.选择任意一种方式进行信令通信。(信令处理层)
3.Janus使用插件式服务。例如常见的插件(业务层)
VideoRoom 多人教育实时互动
VideoCall 两个人之间的实时通信
Streaming 通过ffmpeg 等其他进行推流至此
SIP 可以通过网络与传统数字电话进行通信
TextRoom 文本聊天室
RecordPlay 音视频录制与播放
4.Janus Core是核心层,控制整个传输,协议实现等等。
Medooze架构
缺点:有卡顿现象
Mediosoup架构
与Medooze的区别是媒体音视频部分传输实在独立的C++程序中,Nodejs与它利用管道通信。使用Epoll异步处理模型,使用多进程模型,每个CPU绑定一个进程。只提供一个底层媒体库,业务逻辑需要自行实现。
总结
场景1:
性能最好的 ,Mediosoup架构。
场景2:
完备性(应用,负载等):Licode架构。
场景3:
性能,完备性兼容:Janus SFU架构。
场景4:
各方面功能性能都比较兼容的:Medooze架构。