浅谈多人音视频的传输架构

用户1097444

发布于 2022-06-29 15:02:49

1K0

发布于 2022-06-29 15:02:49

文章被收录于专栏：腾讯IMWeb前端团队

在实际的多人音视频通讯场景中，1 对 1 通讯只是诸多场景的一种。而在教育或者会议的场景中，更多是 1 对多或者是多对多通讯。综合目前多方通信方案来看，基本都是以下三种架构方案：Mesh 架构、MCU 架构、SFU 架构。

一、Mesh 架构

如上图所示：5 个浏览器，两两建立 p2p 连接，每个浏览器与其它 4 个建立连接，总共需要 10 个连接，整个传输形成一个网格拓扑结构。如果每条连接占用 1m 带宽，则每个端上行需要 4m，下行带宽也要 4m，总共带宽消耗 20m。他们通过 STUN 服务进行穿越，因此不需要媒体服务，每个浏览器上要处理音视频 “编码 / 解码”，一般这种架构只能支持 4-6 人左右，不过优点也很明显，没有中心节点，实现很简单。

优势：Mesh 实现起来技术难度是最小的，实现起来最简单；Mesh 架构对服务器资源占用是最小的，只需要一个 ICE 服务器用来实现 P2P 穿越就行了，Mesh 架构是真正的去中心化，对服务器资源占用是最小的，还有可以充分的利用了端上的算力，边缘计算的时代已经来了，理论上节省不少成本。
劣势：首先 Mesh 架构对流量或带宽要求比较大，其对浏览器 / 端上的上行宽带占用比较大，而上行宽带相对于下行宽带来说一般是比较小的。虽然节省了服务资源，但端上的资源是一个考验。另一方面，如果有部分人由于网络复杂情况而无法穿越，单独处理这部分端上用户，是比较复杂的，也需要额外的兜底保障策略。

二、MCU (MultiPoint Control Unit)

如上图所示：每个浏览器仅与中心的 MCU 服务连接，有这个中心服务负责处理所有的视频编码、转码、解码、混合等复杂逻辑。而这个处理过程如下图所示：

接收发送端发送的音视频流。
将音视频流的数据进行解码。
对于视频流，要进行重新布局，混合处理。对于音频流，要进行混音、重采样处理。
将混合后的音视频进行重新编码。
发送给接收端的浏览器。中心化的统一处理流程，各端表现更加一致和好处理。而从宽带使用上看，因为每个浏览器只要 1 个连接，所以整个网络仅消耗 5 个连接，带宽占用 (包括上行、下行）共 10m。从实践上说，这个架构可以支持更多的人同时音视频通讯，比较适合多人会议的场景。

优势：MCU 架构占用带宽最小，每个浏览器 / 端上只发送和接收一个视频流，同时从服务器端获取一份混合过的媒体流还是按照 1M 算，那每个浏览器 / 端上上下行总共就是 2M；综合来看 MCU 架构一个端同时能承受更多的人开启视频。另一方面，由于中心化的处理流程，通过中心服务便捷码可以屏蔽不同设备的处理差异，满足更多设备集成，端上的处理和表现更加一致。如今，MCU 技术非常成熟，在实际应用的使用非常广泛。
劣势：显而易见，MCU 服务的在进行解码、编码等处理时，运算量消耗很大，因此服务成本比较高，而在实践中容量也是比较有限的。其次编解码和混流等操作会引入不小的延迟，在对于实时性要求比较高的场景，可能不太合适。由于只有一路下行，观看体验比较一致，但也带来另一个问题，端上无法再灵活特殊处理（比如特殊布局、单独美颜）。

三、SFU (Selective Forwarding Unit)

如上图所示：每个浏览器与中心 SFU 服务连接，但与 MCU 服务不同的是，SFU 服务只负责转发，所以服务器的压力会低很多。每个浏览器用一个上行连接传输自己的音视频，另外还要有 n-1 个连接用于下载其它音视频数据。所以总连接数为 5*5，消耗的带宽也是最大的，如果每个连接 1M 带宽，总共需要 25M 带宽。相比 MCU，SFU 在结构上相对简单很多，只是接收流然后转发给其他人。这也带来了其他好处：比如根据带宽和网络延时，单独调整音视频的码率等。另外也能灵活调整画面布局。

优势：SFU 服务器接到 RTP 包后直接转发；不做编码、转码、解码、混合这些算力要求较高的工作；所以 SFU 架构服务端压力相对较小。
劣势：由于是数据包直接转发，每个端上看到的多路视频，可能会出现不同步，需要端上对每路音视频做同步处理。在每路视频布局和渲染展示上，端上也要额外处理。整体上在通用性、一致性方面比较差。最后则是对于端上的带宽要求比较高。