【音视频】Mesh、Mcu、SFU三种框架的总结

Mesh架构流量或带宽要求比较大，Mesh架构是利用Webrtc对等连接，在参与会议的各方之间开辟UDP通道，也就是两两进行P2P连接，把媒体流发给参与会议的各方，同时从参与会议的其它方获取媒体流，如上图四个参与方，总共8个连接，如果每个通道占用1M带宽，那每个端需要把自己的流发给其它三个端，也就是上行是3M带宽，同时从其它3个端获取流，也就是下行3M带宽，这样每个端上下行总共6M带宽；
Mesh架构对端的能力要求也是比较高，毕竟参与会议的各方的媒体流的编解码都是在端上面来处理的，图上面的4个参与会议方，那每个端的处理量就是4；结合上面可以看出Mesh一个端能承受的同时开视频的人员更少
Mesh架构不利于媒体的集中处理；例如媒体的录制，你如果不觉得带宽或者流量是问题，再从端上传一份媒体到存储服务器那又另当别论；又或者小哥哥小姐姐直播了一些不该直播的无法进行识别或处理了；再者集成我大讯飞的翻译咋办？不能没有我大讯飞的翻译啊，当然端上做也是可以的，但是毕竟端上算力是有限的；
但是Mesh实现起来技术难度是最小的，实现起来最简单；Mesh架构对服务器资源占用是最小的，只需要一个ICE服务器用来实现P2P穿越就行了，Mesh架构是真正的去中心化，对服务器资源占用是最小的，还有可以充分的利用了端上的算力，边缘计算的时代已经来了，节省不少成本；

MCU架构(MultiPoint Control Unit)

MCU架构对服务器端压力比较大，MCU架构需要一个中心化的MCU服务器，编码、转码、解码、混合都在服务器端做；
如上图MCU架构下的参会的4个端把自己的媒体流上缴到MCU服务器，然后MCU服务器对4个媒体流解码后进行合并，4个流合并成一个媒体流，再发给4个参会人员；因此服务器的压力特别大；所以单台服务器能承受的参会人员特别少，当然一些财大气粗的企业可以加服务器，加高级的GPU
MCU端上各种控制更加复杂 ，现在我和漂亮小姐姐聊天，小姐姐是我日思夜想的，我现在想把她的画面调大，这个实现起来就很麻烦了，因为下发的媒体流是合并的，也就是一个视频流；当然不是不可实现，通过信令服务器下发一个重新合屏的信令我们还是可以看到清晰的小姐姐的画面的；只是相对来讲实现更麻烦；
又比如我希望参会的小姐姐们看到群里最靓的我，那我对我自己上滤镜美白那可就麻烦了
MCU架构占用带宽最小，从前面的描述和从上图中我们可以看到4个参会人员每个人上交一份媒体流如果还是按照1M来算，那上行每个端1M，同时从服务器端获取一份混合过的媒体流还是按照1M算，那每个端上下行总共就是2M；结合上面所述MCU架构
一个端同时能承受更多的人开启视频

SFU架构(Selective Forwarding Unit)

SFU架构服务端压力相对较小，SFU架构看似和MCU一样都有一个中心化的服务器，但是SFU的服务器只负责转发媒体或者存储媒体；不直接做编码、转码、解码、混合这些算力要求较高的工作；SFU服务器接到RTP包后直接转发；
SFU架构占用带宽适中，例如上图，SUF架构参与会议的4个端每个端首先要把自己的流发给服务器，所以每个端上行1M带宽，同时从服务器获取转发过来的其它3个参会人员的媒体流也就是下行3M，这样每个端上下行加一起就是4M；所以它占用端上的带宽在Mesh架构和SFU之间；这种适中的带宽占用在即将到来的5G时代你可以想象！！！！
SFU架构对端和媒体流的控制更简单，还是上面的场景，我想仔细端详日思夜想的小姐姐将她的画面调大，只需要在端上直接放大就行了；另外整个会议中只让我成为最靓的仔，进行美颜啥的实现起来也不算是啥问题了，虽然对端的要求高，但是现在手机或者电脑算力过剩啊，边缘计算发挥到极致，哈哈……，为企业省钱

总结

互联网时代要求更个性化的体验（美颜，更个性化的控制等等），更大的容积率（也就是更多的用户同时在线）；总的来说SFU架构更适合互联网时代；ZOOM会议和腾讯会议这两个比较出名的互联网会议系统都是SFU架构；所以跟风一波后续深入的研究SFU架构；
虽然SUF架构对端的算力要求比较高，更多的计算放到了端上，不过在视频会议或者直播的场景下面，跟多的是一个大画面，其它若干个小画面，而且通过交互控制，例如：同时只显示若干个小画面，滚动的时候动态的再获取其它的参会人员的视频生成小画面；
SFU只负责转发流，所以更高的并发，同时它逻辑简单，更容易的构建高负载架构

参考文章

一文带你了解webrtc基本原理（动手实现1v1视频通话）_go webrtc-CSDN博客

Webrtc音视频会议之Mesh/MCU/SFU三种架构_webrtc_千里授渔-即构开发者社区 (csdn.net)

dualven_in_csdn