前N篇都是一对一和一对多的音视频和相关功能实现，看起来比较简单，比较轻松的就实现了。但是，实际场景下往往没那么简单，涉及到很多方面，包括软硬件、网络带宽和使用方式等。不过，刚学的话，倒也不用面面俱到，慢慢来吧。这节来看看多人音视频是如何实现的，具体有哪些方案。
目前主流的方案主要有以下三种：
- Mesh 方案
- MCU（Multipoint Conferencing Unit）方案
- SFU（Selective Forwarding Unit）方案
下面分别来详细介绍下这几种方案
Mesh 方案
最简单的实现方案，因为它（基本）不需要任何基础设施。它的实现方案就是一对多直播模式的升级版，即每个人都是主播，都与其他用户建立起连接。比如有四个用户，A、B、C和D需要建立连接，他们的连接结构会如下所示：
他们每个人都同其他人建立了连接，类似于一个网格拓扑结构。
可以简单思考一下需要连接多少次：
- 当只有A和B，1 次
- 当有ABC三个人，2 + 1 = 3 次
- 当有ABCD四个人，3 + 2 + 1 = 6 次
- 当有ABCDE五个人， 4 + 3 + 2 + 1 = 10 次
- 当有N个人， 有 N * (N - 1) / 2 次
可以看到，当人数增多时，连接数会快速增长，需要的带宽也是很高的。所以一般控制在4-5人之内算是比较好处理的。
它具有的优势如下：
- 不需要额外的服务器，只需要一个信令服务器即可。
- 每个人都同其他人直接连接，媒体流直接在客户端之间传输，延迟很低。
当然，缺点也是比较明显的：
- 带宽消耗大，参与者数量增加时性能下降快。适用于少量参与者(通常4-5人以内)的场景
- 当其中某个人无法实现NAT洞穿时，就会出现问题，需要考虑到替代方案。
MCU 方案
这个方案的实现方式是：由中心服务器与每个用户保持一对一连接，每个用户将自己的媒体流发送给中心服务器，然后中心服务器所接收到的媒体流进行解码、混合再重新编码，之后再发送给每个用户。这种方案的结构如下所示：
可以想象，所有媒体流都交给中心服务器进行处理，那么它的压力是非常大的，需要强大的服务器来处理音视频混合。
它具有以下优势：
- 所有人看到的都是一个画面，因为是由中心服务器统一发送的，体验感不错。
- 中心服务器统一解码和编码，可以屏蔽不同用户的设备差异，不会出现无法播放的问题，能更好的服务大多数用户。
- 客户端压力小，支持大量用户（相对的，其实也不是很大，看服务器）。
缺点如下：
- 解码、混流和编码都需要消耗大量CPU资源和进行大量运算，需要强大的服务器，得烧钱
- 解码、混流和编码还需要时间，所以会增加延迟，同时会降低画质
SFU 方案
这种方案是当下比较流行的解决方案，相对上面两种来说，成本较低、性能和效果较好，但这就需要较高的技术了。毕竟，没有什么是完美的。
该方案的实现类似 MCU方案，也是架一个中心服务器，也是和所有用户保持一对一连接，但是这个服务器并不会处理任何媒体流，就是没有编解码、混流的过程，而是直接转发给每个用户。注意，这里转发给用户是类似与 Mesh 方案，即有 ABC 三个用户， 中心服务器会给 A发送BC的媒体流，给B发送 AC的媒体流，给C发送 AB的媒体流。
到这里，是不是有点顿悟，这不就是结合了 Mesh方案 和 MCU方案 吗？ 用到了 MCU方案的 中心服务器处理模式，又结合了 Mesh方案的连接模式。
当然，还有一个最大的好处就是，根据用户的客户端能力选择性的转发对应的媒体流。比如客户端的带宽高、延时低，则可以全量转发媒体流；如果带宽不咋地，延时又高，则可以剔除一些无关的媒体数据、或者降低画质。当网速恢复后，又能全量转发了。很灵活，但对于技术就需要较高的要求了。还得考虑到不同的客户端设备，必须做出适配。
这种方案的结构如下所示：
它的优势如下：
- 只负责转发流，不进行混合。所以具有较低的延迟，并且没有画质损失。
- 直接转发，对CPU资源的消耗较低，服务器凑合凑合能用就行。
- 灵活性高，能适应不同的网络状况和设备类型。
缺点也是有的：
- 每个用户的网络状况不同、延时不同，所以看到的画面可能不会同步、画质也是会不同。
- 技术要求高，需要适配不同客户端。还需要考虑到不同网络情况下，需要对媒体流进行处理。
这里还需要补充SFU方案下的两种常用模式：
- Simulcast 模式
该模式允许同时传输多个不同分辨率和比特率的视频流，它的实现思路是客户端发送多个不同分辨率和比特率的视频流（一般为三路，如 1080P、720P、360P），然后服务器接收所有流，根据接收端的网络状况和设备能力，选择最合适的流进行转发。在此过程中，服务器可以动态调整转发的流，以适应网络状况的变化。
比如说A用户的网络很好，那么就可以给A用户发送1080的媒体流；而B用户是移动端的，网速不稳定，则可以发送360或720的媒体流。
它的优点如下：
- 提供多种质量级别，适应不同的网络条件。
- 减少服务器的处理负担，因为服务器不需要进行视频混合。
缺点也有：
- 需要客户端发送多个流，增加了客户端的带宽需求。
- SVC 模式
SVC（Scalable Video Coding，可伸缩视频编码）是一种视频编码技术，允许视频流在不同的分辨率、帧率和质量级别上进行编码。就是说当客户端在发送媒体流时会进行编码，将视频流编码成多个层次，每个层次代表不同的分辨率或质量。越上层的分辨率和质量越高，越底层则越差。接收端可以根据自身的能力和网络状况，选择解码一个或多个层次。这样只传输必要的层次，优化带宽使用。
它的优点如下：
- 高效利用带宽，提供更好的视频质量。
- 接收端可以灵活选择解码层次，适应不同的网络条件和设备能力。
缺点也有：
- 需要支持SVC的编码器和解码器。
- 实现复杂度较高。
| 特点 | Simulcast | SVC |
|---|---|---|
| 编码方式 | 多个独立流 | 分层编码 |
| 带宽需求 | 高（客户端发送多个流） | 低（只传输必要的层次） |
| 服务器处理 | 选择转发合适的流 | 转发分层流 |
| 实现复杂度 | 中等 | 高 |
| 适应性 | 高 | 高 |
Simulcast 适用于需要快速实现且客户端带宽充足的场景。
SVC 适用于带宽受限且需要高效利用带宽的场景。
对比
看了上面三种方案，来看看如何选择
- 当用户数量少，且设备不错，或者都是内部网络，可优先考虑Mesh方案
- MCU方案的话，假如需要兼容老旧设备的话可以考虑硬件MCU方案。还有，假如非常有钱，也可以强上软件MCU方案
- 其他情况都考虑使用 SFU方案
小节
本小节介绍了实现多人音视频的三种主流方案，Mesh方案、MCU方案和SFU方案。Mesh方案简单好用，唯一缺点就是只能4-5个人使用，再多就很难顶了，投入将成倍增长。MCU方案中硬件是比较成熟的，以前也大都是用这种方案；软件的话则消耗很大，不是很推荐。SFU方案则是后起之秀，推荐使用这个，难点就在于技术要求比较高，这个相对于前面两种来说还算是能接受吧。
下一小节来看看如何使用Mesh方案实现多人音视频通话，冲！！
