您好,欢迎来到划驼旅游。
搜索
您的当前位置:首页WebRTC进阶流媒体服务器开发(一)多人互动架构

WebRTC进阶流媒体服务器开发(一)多人互动架构

来源:划驼旅游
WebRTC进阶流媒体服务器开发(⼀)多⼈互动架构

⼀:多⼈互动架构⽅案

(⼀)WebRTC回顾,两层含义:

1.WebRTC是google开源的流媒体客户端,可以进⾏实时通讯,主要应⽤于浏览器之间进⾏实时通讯,也可以单独编译在⾃⼰的应⽤中2.WebRTC也是⼀套规范,只对客户端做了定义,如何进⾏媒体协商、通信流程...;对于服务端,⽐如信令服务端、中继服务,并没有在WebRTC中定义,由⼚商定义;对于多⼈互动⽅案也没有定义

(⼆)3种框架进⾏多⼈互动

Mesh⽅案:从WebRTC客户端演变过来,多⼈互动--->变为多个1V1通讯,会导致⽹络连接过多,任⼀个客户端都需要与其他客户进⾏连接,带宽占⽤过多,不适⽤商业

MCU⽅案:硬件演变为软件,包含⼀个中⼼服务器。中⼼服务器会对多路视频进⾏混屏(解码、编码),降低带宽,占CPU,⽀持的同时在线⼈数有限。此外,客户端⽆法对其进⾏控制,灵活性较差。

SFU⽅案: 简单、主流,不对数据处理,当服务器收到数据后直接进⾏数据转发,只进⾏转发。每个客户端都会收到其他客户端通过服务器转发过来的数据,但是相对于Mesh,建⽴的连接只和服务器个数有关。并且相对于MCU,客户端对于接受的其他各个客户端的数据可以进⾏灵活控制。缺点:相对有MCU传输的数据更多,造成客户端到服务端的带宽占⽤过⾼,带宽不够时会造成丢包,服务质量⽆法保证!改进⽅法:1.降低码流(上传时/发送时)2.根据H2中SVC分层⽅式,将⼀路视频分为核⼼层、扩展层、边缘层,⼀层⽐⼀层清晰(增量累加),当带宽⾜够时可以全部下发给客户端,不够时可以选择传输核⼼层或者核⼼层+扩展层从⽽降低下⾏带宽数量,缓解质量不⾜问题

⼆: 架构模型详解

(⼀)Mesh架构模型详解

1. 1V1通讯模型

2. Mesh通讯模型(未画出信令服务器)

Mesh⽅案,不依赖于服务器进⾏数据中转(不会⾛TURN),是各个端之间建⽴连接。

内部同1V1进⾏设备检测、数据编解码、媒体协商、建⽴连接、发送数据。唯⼀区别就是1V1可以通过TURN转发。

Mesh⼀般使⽤P2P直连,不会经过TURN服务器转发,太复杂,不易管理。但是国内需要考虑穿透率,所以该⽅案⼀般⽤在局域⽹中进⾏使⽤和学习!

(⼆)MCU架构模型详解

在MCU中⼼服务器中,存在多个Room,这⾥只选取左侧的进⾏讲解:

1.对于每⼀个客户端C1、C2...C4,进⼊房间中,在房间中(服务器端)都有对应的模块进⾏连接,客户端进⾏通讯的数据,⽐如⾳频数据、视频数据都通过该连接传递给服务端。

2.服务端模块收到数据后,会对数据进⾏解复⽤,将⾳视频数据拆解,将⾳频放⼊⾳频处理模块,将视频放⼊视频处理模块,实现对数据解码,然后进⾏混屏,之后进⾏编码压缩。返回压缩数据(⼀路流)到各个客户端。

缺点:服务端⽆法⽀持⼤量客户端,最多⽀持⼏⼗路流处理;客户端获取的数据固定(由服务端处理后的),⽆法进⾏编辑(拉伸、改变清晰度)

(三)SFU架构模型详解(主流)

与MCU类似,只是对于SFU⽽⾔,不对媒体流进⾏解码、混屏、编码;⽽是直接进⾏转发!!对于终端,接受的数据是原始分辨率,可以对数据进⾏处理,⽐MCU更加灵活。

缺点:对于接受端的下⾏带宽有考验,如果带宽不允许,可能导致服务质量不⾜

解决⽅案:

1.simulcast分层,可以设置成两层、三层或是四层甚⾄更⾼层次的分辨率,⽐如最⾼层是0X360的分辨率,下⼀层是240X120的分辨率,再⼀层是80X60的分辨率。总之就是按⽐例的缩放。在上传的时候将三层同时上传,下发的时候SFU会判断整个带宽能否承载下⾏的数据,如果不能承载便选择低⼀个层次的分辨率看能否承载,若不能承载,再选择更低层次的,依次下去…

2.根据H2中SVC分层⽅式,将⼀路视频分为核⼼层、扩展层、边缘层,⼀层⽐⼀层清晰(增量累加,各层之间相互依赖),当带宽⾜够时可以全部下发给客户端,不够时可以选择传输核⼼层或者核⼼层+扩展层从⽽降低下⾏带宽数量,缓解质量不⾜问题。

simulcast和SVC不能混⽤。这两个相⽐,simulcast的操作更简单⼀些,实⽤性更⾼⼀些,国内的 声⽹ 便使⽤的这种⽅式。SVC更复杂⼀些,国外的 zoom 、思科 的解决⽅案便采⽤的这种⽅式。

三:流媒体服务器架构和特点

已知的多⽅通信框架有:Mesh MCU SFU 三种。

其中SFU是⽬前最优的⼀种多⽅通信架构⽅案,⽽且这种⽅案⽬前已经有⽐较流⾏的开源项⽬:Licode Janus-gateway Mediasoup Medooze下⾯简单的对这4种⽅案进⾏分析:

(⼀)Licode架构

Licode 既可以⽤作SFU 类型的流媒体服务器,也可以⽤作 MCU 类型的流媒体服务器。⼀般情况下,它都被⽤于SFU类型的流媒体服务器。Licode 不仅仅是⼀个流媒体通信服务器,⽽且还是⼀个包括了媒体通信层、业务层、⽤户管理等功能的完整系统,并且该系统还⽀持分布式部署。下⾯这张图是 Licode 的整体架构图:

如上图所⽰,从⼤的框架上来看,Licode框架被分为2部分:服务端和客户端

1.客户端讲解(简单)

客户端被分为了3个部分:ClientAPP(信令通讯,⽐如房间操作、媒体协商...)、Eriza.js(对房间相应逻辑进⾏控制)、WebRTC(抓取⾳视频数据分享和展⽰)

2.服务端讲解

通过上图可以看出,Licode 从功能层⾯来讲分成三部分,即 Nuve 、ErizoController 和 ErizoAgent 三部分,它们之间通过消息队列进⾏通信。

Nuve 是⼀个 Web 服务,⽤于管理⽤户、房间、产⽣ token 以及房间的均衡负载等相关⼯作。它使⽤ MongoDB 存储房间和 token 信息,但不存储⽤户信息。

ErizoController,⽤于管理控制,信令和⾮⾳视频数据都通过它接收。它通过消息队列与 Nuve 进⾏通信,也就是说 Nuve 可以通过消息队列对 ErizoController 进⾏控制。ErizoAgent,⽤于⾳视频流媒体数据的传输,可以分布式布署。ErizoAgent 与 ErizoController 的通信也是通过消息队列,信令消息通过 ErizoController 接收到后,再通过消息队列发给 ErizoAgent,从⽽实现对 ErizoAgent 进⾏控制。

通过上⾯的描述,可以知道 Licode 不仅仅是⼀个 SFU 流媒体服务器,它还包括了与流媒体相关的业务管理系统、信令系统、流媒体服务器以及客户端 SDK 等等,可以说它是⼀个⽐较完善的产品。Licode缺点:

在 Linux 下⽬前只⽀持 Ubuntu 14.04 版本,在其他版本上很难编译通过。(现在不清楚,毕竟已经过去⼀段时间)Licode 不仅包括了 SFU,⽽且包括了 MCU,所以它的代码结构⽐较重,学习和掌握它要花不少的时间。

Licode 的性能⼀般, 如果你把流媒体服务器的性能排在第⼀位的话,那么 Licode 就不是特别理想的 SFU 流媒体服务器了。

(⼆)Janus SFU架构

Janus 是⼀个⾮常有名的 WebRTC 流媒体服务器,它是以 Linux 风格编写的服务程序,采⽤ C 语⾔实现,⽀持 Linux/MacOS 下编译、部署,但不⽀持 Windows 环境。

Janus 的架构组成:

流程如Medooze架构图流程⼀致!!(后⾯)

上⾯这张图是 Janus 的整体架构图。Janus 可以被分为以下三部分: Janus CORE、Janus Plugin 以及信令接⼝组成

1.信令接⼝,Janus ⽀持的信令协议⽐较多,如 HTTP、WebSocket、RabbitMQ 等。这些信令协议使得 Janus 具有⾮常好的接⼊性。因为很多公司喜欢各种不同的协议,如有的喜欢 websocket,有的喜欢http,proto等。因此 Janus 在信令接⼊⽅⾯具有很⼤的优势。

2.Janus Plugin,Janus 的业务管理是按照 Plugin 的⽅式管理的,因此你可以在Janus中根据⾃⼰的需要实现⾃⼰的业务插件。实际上,对于⼀般性的需求 Janus 已经相关的插件。如:

SIP:⽤于与传统电话设备对接,这个插件使得 Janus 成了 SIP ⽤户的代理,从⽽容许 WebRTC 终端在 SIP 服务器(如 Asterisk)上注册,并向 SIP 服务器发送或接收⾳视频流。

TextRoom:该插件使⽤ DataChannel 实现了⼀个⽂本聊天室应⽤。

Streaming:⽤于⼴播,也就是我们通常所说的⼀⼈共享,多⼈观看的直播模式;它容许 WebRTC 终端观看 / 收听由其余⼯具⽣成的预先录制的⽂件或媒体。VideoRoom:它实现了视频会议的 SFU 服务,实际就是⼀个⾳ / 视频路由器,⽤于多⼈⾳视频互动,像⾳视频会议,在线教育都可以通过该插件来实现。VideoCall:这是⼀个简单的视频呼叫的应⽤,容许两个 WebRTC 终端相互通讯,⽤于 1:1 的⾳视频通信。它与 WebRTC 官⽹的例⼦类似(https://apprtc.appspot.com),不⼀样点是这个插件要通过服务端进⾏⾳视频流中转,⽽ WebRTC 官⽹的例⼦⾛的是 P2P 直连。RecordPlay:该插件有两个功能,⼀是将发送给 WebRTC 的数据录制下来,⼆是能够经过 WebRTC 进⾏回放。

3.Janus Core 是Janus的核⼼,其作⽤是处理流的转发,各种协议的接⼊。以浏览器为例,要想让浏览器接⼊到 WebRTC 流媒体服务器上,那流媒体服务器必须要⽀持STUN、DTLS、SRTP、ICE 等协议。⽽ Janus Core 就是专门做这事⼉的。

Janus 的整体架构:

Janus 分为两层,即应⽤层和传输层

插件层⼜称为应⽤层,每⼀个应⽤都是⼀个插件,能够根据⽤户的须要动态地加载或卸载掉某个应⽤。插件式架构⽅案是很是棒的⼀种设计⽅案,灵活、易扩展、容错性强,尤为适⽤于业务⽐较复杂的业务,但缺点是实现复杂,成本⽐较⾼。传输层包括媒体数据传输和信令传输。

媒体数据传输层主要实现了 WebRTC 中须要有流媒体协议及其相关协议,如 DTLS 协议、ICE 协议、SDP 协议、RTP 协议、SRTP 协议、SCTP 协议等。

信令传输层⽤于处理 Janus 的各类信令,它⽀持的传输协议包括 HTTP/HTTPS、WebSocket/WebSockets、NanoMsg、MQTT、PfUnix、RabbitMQ。不过须要注意的是,有些协议是能够经过编译选项来控制是否安装的,也就是说这些协议并⾮默认所有安装的。另外,Janus 全部信令的格式都是采⽤ Json 格式。

Janus 总体架构采⽤了插件的⽅案,这种架构⽅案很是优秀,⽤户能够根据本⾝的须要很是⽅便地在上⾯编写本⾝的应⽤程序。并且它⽬前⽀持的功能很是多,好⽐⽀持 SIP、RTSP、⾳视频⽂件播放、录制等等,因此在与其余系统的融合性上有很是⼤的优点。另外,它底层的代码是由 C 语⾔编写的,性能也很是强劲。Janus 的开发、部署⼿册也很是完善,所以它是⼀个很是棒的开源项⽬。因此,它的架构设计⽐较复杂,对于初学者来讲难度较⼤。

(三)Medooze架构

Medooze 的整体架构与 Mediasoup 类似,不过它的信令处理、业务管理以及媒体数据的转发功能都是放在 Nodejs下进⾏统⼀管理的。实际上,这样的管理⽅式也不会对性能造成什么影响,因为重的媒体流的转发⼯作仍然是使⽤的 C++ 在 Nodejs 底层实现的。

Medooze架构流程图:

Medooze架构模型如图中所⽰:使⽤NodeJs实现整个服务(信令交互),在NodeJs下⾯使⽤MediaServer C++作为底层服务器进⾏使⽤(实现媒体流传输)

1.浏览器从服务器获取客户端代码,通过V8引擎,启动底层WebRTC2.浏览器与服务端的MediaServer JS进⾏信令交互、房间操作、媒体协商3.数据传输WebRTC到MediaServer C++

多客户端流程⼀致

Medooze整体架构图:Medooze 的核⼼层:

从⼤的⽅⾯来说,Medooze ⽀持 RTP/RTCP、SRTP/SRCP 等相关协议,从⽽能够实现与 WebRTC 终端进⾏互联。

除此以外,Medooze 还能够接⼊ RTP 流、RTMP 流等,所以你可使⽤ GStreamer/FFmpeg 向 Medooze 推流,这样进⼊到同⼀个房间的其余 WebRTC 终端就能够看到 / 听到由 GStream/FFmpeg 推送上来的⾳视频流了。另外,Medooze 还⽀持录制功能,即上图中的 Recorder 模块的做⽤,能够经过它将房间内的⾳视频流录制下来,以便后期回放。为了提升多⽅通讯的质量,Medooze 在⾳视频的内容上以及⽹络传输的质量上都作了⼤量优化。

Medooze 的控制逻辑层:

是经过 Node.js 实现的,Medooze 经过 Node.js 对外提供了完整的控制逻辑操做相关的 API,经过这些 API 你能够很容易的控制 Medooze 的⾏为了。

Medooze 的业务功能要⽐ Mediasoup 强⼤,像服务端录制、推流这些 Mediasoup 没有的功能它都⽀持。但它性能没有 Mediasoup 做的极致,在Medooze的底层使⽤的poll来处理I/O事件,poll与epoll性能相差距⼤。除此之外,Medooze的业务逻辑也没有Mediasoup简洁;另外与 Janus 相⽐,它的业务管理不如 Janus 灵活,Janus 的插件管理⽅式显然要优于 Medooze 和 mediasoup。

但总的来说,Medooze还是⼀款⾮常不错的 WebRTC 流媒体服务器。虽然有⼀些⼩的暇疵,但还是⾮常不错的⼀款流媒体服务器。

(四)Mediasoup架构

下图是Mediasoup整体架构图:流程如Medooze⼀致(前⾯)!

通过该图我们可以知道 Mediasoup 流媒体服务器是由 Nodejs 和 Mediasoup(C++) 两部分组成。

Nodejs,负责 Mediasoup 的信令接收与业务管理。如创建/消毁房间,创建/关闭⽣产者,创建/关闭消费者等。

Mediasoup(C++),这是⼀个单独的程序,但该程序⽆法直接启动。因为它在内部会判断是否是 Nodejs 将它启动起来了。只有在Nodejs 的 Mediasoup 管理模块加载之后,再将 Mediasoup(C++)启动起来,这样它才能正常⼯作。Nodejs 与 Mediasoup之间通过管道进⾏通信。

在众多的 WebRTC 流媒体服务器中,Mediasoup 可以说是性能最优秀的WebRTC流媒体服务器。它使⽤ C++ 作为开发语⾔,底层使⽤ libuv 处理 I/O 事件。

有很多⼈对 Nodejs ⽐较诟病,认为 Nodejs 提拱不了⾼性能的流媒体服务器。

实际上,如果按照传输的 Nodejs 应⽤开发出的流媒体服务器肯定是不能胜任这项⼯作的。但对于 Mediasoup 来讲,它只不过使⽤ Nodejs 做 信令处理 及 业务的管理 ⼯作,所以它的负担并不重。对性能要求⾼的是媒体数据流的转发⼯作,⽽这部分⼯作是由 Mediasoup(C++)部分实现的。

Mediasoup是多进程程序,他会在业务层控制进程的个数,监听系统的CPU核数,会对每⼀个CPU绑定⼀个Mediasoup进程

⽐如说你的服务器是个 8 核的CPU,那么在业务层你就该启动 8 个Mediasoup进程。通过这种⽅式来达到对 CPU 的充分利⽤。

Meidasoup多进程图:

Host(最⼤的灰⾊底框)中,包含worker⼀、worker⼆、worker3(3个⽩⾊框),能够认为是进程。每⼀个worker中,包含1个或多个router(蓝⾊的⽅⽚花),进程中有1个或多个房间。

router周围有:⾳视频⽣产者(红⾊的输⼊)+ ⾳视频消费者(绿⾊的输出),每⼀个房间有多个⽣产者和消费者。producer:⼀路视频是⼀个⽣产者,⼀路⾳频也是⼀个⽣产者 。consumer:⼀路视频是⼀个消费者,⼀路⾳频也是⼀个消费者 。transport:⼀个Transport 就只关联⼀个⽤户。

Mediasoup中的每个进程称为⼀个 Worker, 你也可以把它理解为⼀个节点,在每个 Worker 中可以有多个 Router。

对于 Router,你站在不同的解度可以有不同的理解。如果你占在应⽤层的⾓度,你可以把它理解为⼀个房间;如果你站在数据流转的⾓度,可以把它理解为⼀个路由器,数据通过 路由器 转发给⽬标⽤户。

⼤的绿⾊箭头下⾯,有灰⾊的Transport字体,分为三种类型,即 WebRtcTransport、PlainRtpTransport 和 PipeTransport。

WebRtcTransport ⽤于与 WebRTC 类型的客户端进⾏链接,如浏览器。

PlainRtpTransport ⽤于与传统的 RTP 类型的客户端链接,经过该 Transport 能够播放多媒体⽂件、FFmpeg 的推流等。PipeTransport ⽤于 Router 之间的链接,也就是⼀个房间中的⾳视频流经过 PipeTransport 传到另外⼀个房间。在每⼀个 Transport (每⼀个⽤户)中能够包括多个 Producer 和 Consumer。

Producer 表⽰媒体流的共享者,它⼜分为两种类型,即⾳频的共享者和视频的共享者。Consumer 表⽰媒体流的消费者,它也分为两种类型,即⾳频的消费者和视频的消费者。

Mediasoup 的实现逻辑很是清晰,它不关⼼上层应⽤该如何作,只关⼼底层数据的传输,并将它作到极致。

(五)如何选择SFU(选择合适的)

实现语⾔:

1.Meooze、Mediasoup、Licode 这三个流媒体服务器的媒体通讯部分都是由 C++ 实现的,⽽控制逻辑是经过 Node.js 实现,所以若是你是 C++ 开发⼈员,且有 JavaScript 技术背景,那么你就应该在这三种流媒体服务器之间选择,由于这样更容易⼊门。

2.⽽ Janus-gateway 是彻底经过 C 语⾔实现的,服务部署是传统的 Linux 风格,所以若是你是 Linux/C 开发者,则应该选择 Janus 做为你的流媒体服务器。

系统特⾊:

1.像 Licode 是⼀个完整的系统,⽀持分布式集群部署,因此系统相对复杂,学习周期要长⼀些。它能够直接布署在⽣产环境,可是⼆次开发的灵活性不够。2.Janus-gateway 是⼀个独⽴的服务,⽀持的信令协议很丰富,并且⽀持插件开发,易扩展,对于 Linux/C 背景的开发者是很不错的选择。3.Medooze 和 Mediasoup 都是流媒体服务器库,对于须要将流媒体服务器集成到本⾝产品中的开发者来讲,应该选择它们。

性能特⾊:

1.Licode、Meooze、Mediasoup、Janus-gateway 单台服务均可以⽀持 500 ⽅参会⼈,因此它们的性能都仍是不错的。2.相对来讲,Licode 的性能与其余流媒体服务器相⽐要低⼀些;

3.Medooze 因为没有使⽤ epoll 来处理异步 IO 事件,因此性能也受到⼀些影响。

不过总的来讲,它们在 500 ⽅的容量下,视频质量均可以获得很好的保证,延迟在 100ms 左右。

因篇幅问题不能全部显示,请点此查看更多更全内容

Copyright © 2019- huatuo6.com 版权所有 湘ICP备2023023988号-11

违法及侵权请联系:TEL:199 1889 7713 E-MAIL:2724546146@qq.com

本站由北京市万商天勤律师事务所王兴未律师提供法律服务