（⾳视频开发）WebRTC进阶流媒体服务器开发-多⼈互动架
构
⼀：多⼈互动架构⽅案
（⼀）WebRTC回顾，两层含义：
1.WebRTC是google开源的流媒体客户端，可以进⾏实时通讯，主要应⽤于浏览器之间进⾏实时通讯，也可以单独编译在⾃⼰的应⽤中
2.WebRTC也是⼀套规范，只对客户端做了定义，如何进⾏媒体协商、通信流程...；对于服务端，⽐如信令服务端、中继服务，并没有在WebRTC中定义，由⼚商定义；对于多⼈互动⽅案也没有定义
（⼆）3种框架进⾏多⼈互动
Mesh⽅案：从WebRTC客户端演变过来，多⼈互动--->变为多个1V1通讯，会导致⽹络连接过多，任⼀个客户端都需要与其他客户进⾏连接，带宽占⽤过多，不适⽤商业
MCU⽅案：硬件演变为软件，包含⼀个中⼼服务器。中⼼服务器会对多路视频进⾏混屏（解码、编码），降低带宽，占CPU，⽀持的同时在线⼈数有限。此外，客户端⽆法对其进⾏控制，灵活性较差。nodejs工作流引擎开源
SFU⽅案：简单、主流，不对数据处理，当服务器收到数据后直接进⾏数据转发，只进⾏转发。每个客户端都会收到其他客户端通过服务器转发过来的数据，但是相对于Mesh，建⽴的连接只和服务器个数有关。并且相对于MCU，客户端对于接受的其他各个客户端的数据可以进⾏灵活控制。缺点：相对有MCU传输的数据更多，造成客户端到服务端的带宽占⽤过⾼，带宽不够时会造成丢包，服务质量⽆法保证！改进⽅法：1.降低码流（上传时/发送时）2.根据H264中SVC分层⽅式，将⼀路视频分为核⼼层、扩展层、边缘层，⼀层⽐⼀层清晰（增量累加），当带宽⾜够时可以全部下发给客户端，不够时可以选择传输核⼼层或者核⼼层+扩展层从⽽降低下⾏带宽数量，缓解质量不⾜问题
⼆：架构模型详解
（⼀）Mesh架构模型详解
1. 1V1通讯模型
WebRTC学习（⼋）1V1⾳视频实时互动直播系统
WebRTC学习（⼋）1V1⾳视频实时互动直播系统（2）
2. Mesh通讯模型（未画出信令服务器）
Mesh⽅案，不依赖于服务器进⾏数据中转（不会⾛TURN），是各个端之间建⽴连接。
内部同1V1进⾏设备检测、数据编解码、媒体协商、建⽴连接、发送数据。唯⼀区别就是1V1可以通过TURN转发。
Mesh⼀般使⽤P2P直连，不会经过TURN服务器转发，太复杂，不易管理。但是国内需要考虑穿透率，所以该⽅案⼀般⽤在局域⽹中进⾏使⽤和学习！
（⼆）MCU架构模型详解
在MCU中⼼服务器中，存在多个Room，这⾥只选取左侧的进⾏讲解：
1.对于每⼀个客户端C1、C
2.服务端模块收到数据后，会对数据进⾏解复⽤，将⾳视频数据拆解，将⾳频放⼊⾳频处理模块，将视频放⼊视频处理模块，实现对数据解码，然后进⾏混屏，之后进⾏编码压缩。返回压缩数据（⼀路流）到各个客户端。
缺点：服务端⽆法⽀持⼤量客户端，最多⽀持⼏⼗路流处理；客户端获取的数据固定（由服务端处理后的），⽆法进⾏编辑（拉伸、改变清晰度）
⾳视频流媒体⾼级开发知识点学习视频点击获取。知识点包括有
FFmpeg/WebRTC/RTMP/RTSP/HLS/播放器-⾳视频流媒体⾼级开发。
⾳视频⾼级开发系统学习视频：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。