流媒体学习之路——初识mediasoup (1)

流媒体学习之路(mediasoup)——初识mediasoup (1)

提示：硕士毕业后转行从事了流媒体相关工作，希望能通过一系列开源项目的学习来扩展自己的知识树。该系列将尝试从著名的C++开源流媒体服务器中学习其设计思想、代码逻辑，并尝试从自己的角度去理解其中的优点与缺点。

---

---

前言

本文作为mediasoup学习的开篇，有必要对目前行业的通用多人互动架构、mediasoup设计思想以及其架构进行了解。参考他人的总结，结合自我思考实现较快速的入门。

---

提示：以下是本篇文章正文内容。

一、多人互动架构

目前，主要有三类多人视频互动架构，分别为：Mesh、MCU、SFU。此处引用了"Mr.Miaow"的图片来进行辅助分析，同时引用了"地铁程序员"对几个模式的解释。

1.1 Mesh

简单来说，一个普通的1对1通信我们需要：
1.传递信令
  会话控制消息：初始化/关闭，各种业务逻辑消息以及错误报告。
  网络相关：外部可识别的IP地址和端口。
  媒体能力：客户端能控制的编解码器、分辩率，以及它想与谁通讯。

2.媒体数据传输
  传递音频、视频等媒体数据。

  下图1是一个不依赖服务器进行中转传输的1对1模型。STUN/TURN服务器可以通过NAT协议在两个用户之间打洞，完成了网络通信。signal server信令服务器则控制了信令传输。最后通过设备采集音视频数据在洞中传输即可完成一对一通信。

图1-1

  当一个频道的用户量增大时，便有Mesh这样的情况（图1-2）

图1-2

  这样的通信形式充分利用了p2p模型的优势，在单个频道用户量较小的时候，这样的优势展现得淋漓尽致：
  1.不需要服务器中转数据，STUN/TUTN 只是负责 NAT 穿越，这样利用现有 WebRTC 通信模型就可以实现，而不需要开发媒体服务器。
  2.充分利用了客户端的带宽资源。
  3.节省了服务器资源，因为服务器带宽往往是专线，价格昂贵，所以这种方案可以很好地控制成本。

  很快，我们会意识到以上的架构存在许多问题。首先这复杂的网络结构看着就让人头疼，而且任何一个链路出了问题排查的复杂度都直线上升。事实上，这类模型还带来了其他方面的影响，这也是彭p2p的局限性：
  1.单条链路的影响因素过多，其质量无法保证；
  2.单个用户都要重复传输大量数据；
  3.无法实现录制功能。
  以上的问题都很大的限制了其多人交互的应用，因此新的多人交互模型应运而生。

1.2 MCU

  其实多人音视频互动模型有两种，我们先介绍MCU（Multipoint Conferencing Unit）。相比Mesh简单粗暴的皮p2p形式，MCU加入了中间服务器，通过中间服务器中转各个用户的数据传输，把相互之间的耦合性大幅降低。同时，MCU的中转服务器还会把多个流媒体数据混合成单一的流传输。大大减少了下行数据量（如图1-3）。

图1-3

  MCU技术非常成熟，在硬件视频会议中应用非常广泛。作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。
  同时，它也存在一些不足：
  1.重新解码、编码、混流，需要大量的运算，对 CPU 资源的消耗很大；
  2.重新解码、编码、混流还会带来延迟；
  3.由于机器资源耗费很大，所以 MCU 所提供的容量有限，一般十几路视频就是上限了。

1.3 SFU

SFU（Selective Forwarding Unit），这个方案采用中间转发的方式。在中转服务器上只做数据转发不做编解码处理，这样有效的降低了服务器的资源消耗，同时大大降低了链路延迟（如图1-4）。

图1-4

  正如前面所说，SFU降低了服务器的资源消耗、提高了实时性。不仅如此，其简单的架构带来了极大的灵活性，能够更好地适应不同的网络状况和终端类型。
  同样，SFU 有优势，也有不足，主要表现是：
  由于是数据包直接转发，参与人观看多路视频的时候可能会出现不同步；相同的视频流，不同的参与人看到的画面也可能不一致。参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难。总之，整体在通用性、一致性方面比较差。通过上面的分析和比较，综合它们各自的优劣情况，我们可以得出 ，SFU 是三种架构方案中优势最明显而劣势又相对较少的一种架构方案。无论是从灵活性上，还是音视频的服务质量、负载情况等方面上，相较其他两种方案，SFU 都有明显的优势，因此这种方案也被大多数厂商广泛采用。

1.4 小结

  以上主要介绍了三种多方通信的架构，分别为Mesh、MCU、SFU。整体来说，由于各方面限制，Mesh 架构在真实的应用场景中几乎没有人使用，一般刚学习 WebRTC 会考虑使用这种架构来实现多方通信。MCU 架构是非常成熟的技术，在硬件视频会议中应用非常广泛。像很多做音视频会议的公司之前都会购买一套 MCU 设备，这样一套设备价格不菲，最低都要 50 万，但随着互联网的发展以及音视频技术越来越成熟，硬件 MCU 已经逐步被淘汰。当然现在也还有公司在使用软 MCU，比较有名的项目是 FreeSWITCH，但正如我们前面所分析的那样，由于 MCU 要进行解码、混流、重新编码的操作，这些操作对 CPU 消耗是巨大的。如果用硬件 MCU 还好，但软 MCU 这个劣势就很明显了，所以真正使用软 MCU 架构方案的公司也不多。SFU 是最近几年流行的新架构，目前 WebRTC 多方通信媒体服务器都是 SFU 架构。"地铁程序员"的博客还介绍了Simulcast 模式、 SVC 模式，感兴趣的同学可以去看看。

二、mediasoup架构分析

提示：mediasoup后端的信令处理是基于node.js设计的，node.js简单直接，虽然在性能上稍显不足。但作为上层信令处理并不会对整体性能产生太大的影响。在这里主要介绍一下C++编写的流媒体服务器部分。

  首先是官网上的示例图https://mediasoup.org/documentation/v3/mediasoup/design/，图2-1：

图2-1

  这个图主要展示的是整个链路的模块图，比较直接易懂。首先就是音视频数据的生产者通过webrtc或者普通rtp协议的传输方式到达服务器。服务器会通过一个“路由”的方式转发给其他参与者（消费者）或者转发给其他worker。
  那以上提到的几个点，比如：路由、worker、生产者、消费者、参与者到底是什么意思呢，我简单的做以下总结。
  1.worker：其实mediasoup处理包转发的过程是单线程的，它只需要快速的转发媒体数据包。但现在的服务器大部分都提供了多个核，为了不浪费资源，它通过起多个进程来实现充分利用，因此每个worker可以简单的理解为一个转发服务器进程。
  2.生产者与消费者：其实比较好理解。就是数据推流方和拉流方的区别。
  3.路由：事实上，webrtc是一个p2p的模型，而mediasoup就是基于webrtc搭建一个中心转发服务器，因此它就类似于一个媒体数据转发的“路由器”。互相互动的用户将会被分配在一起转发交互，因此分出了许多的router。

  提示：其实还有一个比较重要的点，就是Transport相关的，因为这部分涉及了Webrtc我想顺手记录一下相关的学习内容。因此放到后续的内容中更新吧。
  

  再借用一张更详细的图片，从这张图片中更容易理解上述的一些概念。

三、总结

  以上只是简单介绍了mediasoup的一些背景基础以及其基本的构架，mediasoup是非常有名的Webrtc开源项目。在后续的阅读中将会有大量与Webrtc相关的内容，这一系列文章的目标仅仅是作为学习笔记，如有缺陷欢迎讨论。

作者：Mr.Miaow 地址：https://miaopei.github.io/2019/10/21/WebRTC/mediaserver-02/
作者：地铁程序员 地址：https://www.cnblogs.com/yiyi17/p/12076657.htm