Janus流媒体服务器框架分析

2023-10-23 09:33:52

Janus流媒体服务器框架分析

目录

  1. webrtc多方通信架构
  2. Janus流媒体服务器

1. webrtc多方通信架构

1. Mesh 方案

  1. Mesh方案即多个终端之间两两进行连接，形成一个网状结构。
  2. 比如 A、B、C 三个终端进行多对多通信，当 A 想要共享它的音视频流时，它需要分别向 B 和 C 发送数据。当B想要共享媒体，就需要分别向 A、C 发送数据，依次类推。
  3. Mesh方案对各终端的带宽要求比较高。
  4. 优点：
    1. 不需要服务器中转数据，STUN/TUTN 只是负责 NAT 穿越，利用现有 WebRTC 通信模型就可以实现，而不需要开发媒体服务器。
    2. 充分利用了客户端的带宽资源。
    3. 节省了服务器资源，因为服务器带宽往往是专线，价格昂贵，所以这种方案可以很好地控制成本。
  5. 缺点：
    1. 共享端共享媒体流的时候，需要给每一个参与人都转发一份媒体流，对上行带宽的占用很大。参与人越多，占用的带宽就越大。除此之外，对 CPU、Memory 等资源也是极大的考验。客户端的机器资源、带宽资源往往是有限的，资源占用和参与人数成线性相关的。这样导致 多人通信的规模非常有限，超过 4 个人时，就会有非常大的问题。
    2. 在多人通信时，如果有部分人不能实现 NAT 穿越，还想与其他人互通，就显得很麻烦，需要做出更多的可靠性设计。
      Janus流媒体服务器框架分析

2. MCU（Multipoint Conferencing Unit）方案，

  1. MCU方案由一个服务器和多个终端组成一个星形结构。
  2. 各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。
  3. 实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
  4. 优点：
    1. 技术成熟，在硬件视频会议中应用非常广泛。
    2. 作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。
    3. 将多路视频混合成一路，所有参与人看到的是相同的画面，客户体验好。
  5. 缺点：
    1. 重新解码、编码、混流，需要大量的运算，对 CPU 资源的消耗很大。
    2. 重新解码、编码、混流还会带来延迟。
    3. 由于机器资源耗费很大，所以 MCU 所提供的容量有限，一般十几路视频就是上限了。
      Janus流媒体服务器框架分析

3. SFU（Selective Forwarding Unit）方案，

  1. SFU方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。
  2. 优点：
    1. 由于是数据包直接转发，不需要编码、解码，对 CPU 资源消耗很小。
    2. 直接转发也极大地降低了延迟，提高了实时性。
    3. 带来了很大的灵活性，能够更好地适应不同的网络状况和终端类型。
  3. 缺点：
    1. 由于是数据包直接转发，参与人观看多路视频的时候可能会出现不同步，相同的视频流，不同的参与人看到的画面也可能不一致。
    2. 参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难。
  4. 目前许多 SFU 方案都支持 SVC 模式和 Simulcast 模式，用于适配 WiFi、4G 等不同网络状况，以及 Phone、Pad、PC 等不同终端设备。

1. Simulcast 模式

  1. Simulcast 模式就是指视频的共享者可以同时向 SFU 发送多路不同分辨率的视频流（一般为三路，如 1080P、720P、360P）。而 SFU 可以将接收到的三路流根据各终端的情况而选择其中某一路发送出去。例如，由于 PC 端网络特别好，给 PC 端发送 1080P 分辨率的视频；而移动网络较差，就给 Phone 发送 360P 分辨率的视频。
  2. Simulcast 模式对移动端的终端类型非常有用，它可以灵活而又智能地适应不同的网络环境。
    Janus流媒体服务器框架分析

2. SVC 模式

  1. SVC是可伸缩视频编码技术，原理是将视频信号编码为两个或更多个码流，这些码流也称为层，这些层中至少有一个是基本层，其余的为增强层。
  2. 基本层包含视频信号基本的也是最重要的信息，接收端接收到基本层就可重建得到基本质量的图像
  3. 增强层包含视频信号的细节信息，接收端将基本层和增强层一起解码，可以重建出更高质量的图像。
  4. 例如将视频分为多层：基本层为240p编码数据，增强层为480p和720p的细节补充编码数据，主播方会把240p、480p的补充编码数据与720p的补充编码数据都发出去，接收方则根据网络环境选择合适的数据包。
  5. 若网络状况良好则选取720p，若网络状况不佳则选择480p甚至240p。
  6. 这样的话无论网络环境如何变化客户端都可以流畅播放，改变的只是画面清晰度。
  7. 所以可以采取大小流模式，例如有些客户需要480p，另一些客户需要720p，那么发送端便可针对240p、480p、720p发两路或者三路，且不会相互干扰。
    Janus流媒体服务器框架分析

4. 开源方案

Janus流媒体服务器框架分析

2. Janus流媒体服务器

  1. 使用的janus版本为0.10.4，下图为janus主要的模块结构，有一些通用工具模块没有列出。
    Janus流媒体服务器框架分析

1. 媒体模块

  1. Janus不是简单转发WebRTC的媒体流，还有⼀定的控制能⼒，因此需要⽀持WebRTC的媒体能⼒，其媒体功能包含以下基本模块：
    1. ICE：打洞，负责与Peer的连通，Janus可以部署在NAT后⾯，使⽤了libnice；
    2. DTLS：UDP版的TLS，就是加密的UDP，WebRTC⽤来传递SRTP的密钥，使⽤了OpenSSL/BoringSSL；
    3. RTP/RTCP：提供RTP/RTCP 封包解包的接⼝，需要发送⼀些WebRTC⽀持的RTCP包，例如FIR、PLI、RR等；
    4. SRTP：加密的RTP，开启后WebRTC传输的RTP负载都是加密的；
    5. SDP：提供SDP封/解包的接⼝，⽤于协商媒体的协议，可以⽤SDP对WebRTC的⼀些功能进⾏设定（编码器优先、码率限制），媒体能⼒的协商；
    6. candidate：⽹络信息，⽹络协商；
    7. SCTP：WebRTC的数据通道使⽤的协议，就是加上了流控的UDP，可以传输任意数据；

2. 信令传输模块

  1. 除了媒体协议，Janus还要提供信令交互的协议，传统的信令协议有SIP、XMPP等，Janus上的信令应⽤协议可以定制，底层主要的传输协议有：
    1. HTTP(s)；
    2. WebSocket(s)；
    3. MQTT；
    4. NanoMsg；
    5. RabbitMQ；
  2. 其中WebSocket使⽤了libwebsockets，HTTP使⽤了libmicrohttpd。

3. 插件模块

  1. Janus的APP⽀持插件式开发，⽬前Janus官⽅给出的插件案例：
    1. Echo Test： 回声测试，⽀持通过按钮控制码率，从这⾥我们也可以学习到如何控制码率.
    2. Streaming：播放视频或⾳频流，可⽤于⽹络直播或转播。
    3. Video Call：⾳视频⼀对⼀通话，类似AppRTC的通话，但是⾳视频数据经过Janus进⾏传输。
    4. SIP Gateway：SIP⽹关演示，允许您在SIP服务器上注册并启动/接收呼叫。
    5. Video Room：视频会议演示，允许您加⼊最多有六个⽤户的视频会议室。.
    6. Audio Room： ⾳频会议演示，不同⽤户之间的⾳频将进⾏混⾳。
    7. Text Room：⽂字聊天室，通过DataChannels进⾏传输。
    8. Voice Mail：演示语⾳邮件功能，可以录制⼗秒的⾳频，然后可以进⾏回放。
    9. Recorder/Playout：演示录制⾳频、视频，然后通过WebRTC进⾏回放.
    10. Screen Sharing：基于视频会议(Video Room )插件实现的屏幕分享功能。
上一篇：LeetCode 1734 解码异或后的排列


下一篇：特殊状态的枚举