JITSI开源视频直播

   JITSI开源视频直播

          徐景周

  • 一、 引言

WebRTC被认为是一种点对点技术,浏览器可以直接通信而无需任何类型的基础设施。此模型足以创建基本应用程序,但难以在其之上实现诸如组通信、媒体流记录、媒体广播或媒体转码之类的功能。

 

  • 二、 WebRTC

2.1 Mesh架构模式

下面是WebRTC Mesh(网格P2P)模式下,1对1的视频通讯如图一所示。

 

 

2.2 Mesh事件序列

如图二所示,Mesh模式下1对1模式下的事件序列图。其中,Coturn Server为开源的NAT穿透服务器(支持STUN/TURN/ICE);Signal Server为信令服务器(可采用开源的Collider/SkyRTC/SignalMaster);

2.3 WebRTC框架

如图三、图四所示。

  • 三、WebRTC流媒体服务器

 3.1 概述

WebRTC规范只定义了实时通信中客户端的行为,而没有规范服务端(包括哪些信令、数据如何流转)的行为。所以,你可以使用WebRTC库方便的实现1:1 实时通信,但对于多人实时互动,通常会使用WebRTC + 流媒体服务器的方案。WebRTC流媒体服务器类似“多媒体中间件”,从源到目的地时,媒体流量会通过该中间件。流媒体服务器能够处理媒体流并提供不同的类型,包括组通信(将一个对等方生成的媒体流分配给多个接收方),混合(将多个传入流转换为一个单一的复合流),转码(在不兼容的客户端之间适应编解码器和格式),录制(以持久的方式存储对等体之间交换的媒体)等。

如图五所示。WebRTC媒体服务器包括SFU(Selective Forwarding Unit,可选择转发单元),MCU(MultiPoint Control Unit,多点控制单元)或混合模式。

3.2 媒体流

如图六、图七所示。WebRTC由语音引擎,视频引擎和网络传输三大模块组成。其中,WebRTC音频处理(VoiceEngine)默认编解码是ISAC(Internet Speech Audio Codec),源码目录“/audio_coding”;视频处理(VideoEngine)默认采集与编解码是I420和VP8(源码目录“/video_coding”)。

3.3 流媒体服务器

基于WebRTC流媒体服务器有很多,如表一所示。下面针对主流的开源服务器进行介绍。

 3.3.1 Janus

Janus 采用C语言实现,是一个非常有名的开源WebRTC流媒体服务器,它是以Linux风格编写的服务程序。支持Linux/MacOS下编译和部署,但不支持Windows环境。

Janus架构如图七所示。Janus分为两层:应用层和传输层。整体架构采用了插件的方案,用户可以根据自己的需要非常方便地在上面编写自己的应用程序。Janus 所有信令的格式都是采用JSON格式。

3.3.2 MediaSoup

MediaSoup使用C++和NodeJS语言实现,底层使用libuv处理I/O事件。

Janus架构如图八所示。MediaSoup流媒体服务器是由NodeJS和 MediaSoup(C++) 两部分组成。其中,NodeJS负责MediaSoup的信令接收与业务管理。MediaSoup(C++)负责媒体数据流的转发工作。

 3.3.3 Medooze 

Medooze使用C++和NodeJS语言实现。Medooze的整体架构与Mediasoup类似,不过它的信令处理、业务管理以及媒体数据的转发功能都是放在NodeJS下进行统一管理的。

Medooze的业务功能要比MediaSoup强大,像服务端录制、推流这些MediaSoup没有的功能它都支持。但它性能没有Mediasoup好,因为Medooze的底层使用的poll来处理I/O事件,poll与epoll性能差距大。除此之外,Medooze的业务逻辑也没有MediaSoup简洁;另外与 Janus 相比,它的业务管理不如Janus灵活,Janus的插件管理方式显然要优于Medooze和MediaSoup。

Medooze架构如图九所示。

3.3.4 Licode

Licode是由C++和NodeJS语言实现。既可以用作SFU类型的流媒体服务器,也可以用作MCU类型的流媒体服务器。Licode不仅仅是一个流媒体通信服务器,而且还是一个包括了媒体通信层、业务层、用户管理以及客户端 SDK 等功能的完整系统,并且该系统还支持分布式部署。

Licode架构如图十所示。其中,媒体通信部分由C++语言实现,而信令控制、用户管理、房间管理用NodeJS实现。Licode从功能层面来讲分成三部分,即Nuve、ErizoController和ErizoAgent三部分,它们之间通过消息队列进行通信。

  • Nuve: 是一个Web服务,用于管理用户、房间、产生token以及房间的均衡负载等相关业务工作。它使用MangoDB存储房间和token信息,但不存储用户信息。
  • ErizoController:用于管理控制,信令和非音视频数据都通过它接收。它通过消息队列与Nuve进行通信,也就是说Nuve可以通过消息队列对 ErizoController 进行控制。
  • ErizoAgent:用于音视频流媒体数据的传输,可以分布式布署。ErizoAgent与ErizoController的通信也是通过消息队列,信令消息通过ErizoController接收到后,再通过消息队列发给ErizoAgent,从而实现对ErizoAgent进行控制。

3.3.5 Kurento

Kurento使用C++开发,有丰富的文档和示例。Kurento是真正完整的多功能媒体服务器,不仅提供媒体服务器功能,还提供其它很多工具(人脸识别,二维码接口,对象追踪等)。

Kurento架构如图十一所示。

 3.3.6 Jitsi

Jitsi是使用Java构建的服务端,底层也是使用C/C++。Jitsi是比较活跃的开源视频会议平台,是一个处理XMPP(前身是Jabber)信号流的SFU,适用于SIP/XMPP视频通话、会议、聊天、桌面共享、文件传输。

Jisti核心组件如图十二所示。

  • Jitsi Video-Bridge:一个XMPP服务器组件,充当媒体服务器,用来在单一的服务器下运行数千个视频流,并且该组件是完全开源的并兼容WebRTC。Jitsi Video-Bridge是Jitsi的核心,将所有人的视频和音频传递给所有参与者,而不是先将它们混合在一起,结果就是延迟更低,质量更好。Jitsi-Video-Bridge 用于处理视频传输,也就是视频流在各参与者之间的转发。如果没有这个组件,各参与者能文字聊天,但无法互相看见。

 

  • Jitsi Meet :通过Jitsi Video-Bridge从而可以提供高质量、可伸缩的视频会议。该组件提供嵌入了WebRTC功能的JavaScript应用程序。一旦应用程序开始执行,信号处理完毕,用户就可以通过Jicofo进行通信,因为Jicofo负责信号处理和视频桥接的中继。Jitsi Meet是建立在Lib-Jitsi之上的,Lib-Jitsi提供了对许多其他API的全面访问,这些API可以让用户对视频会议有更多的控制。主要职责: 创建一个XMPP信令层、初始化与对等点的连接、接收媒体/消息和文件。

 

  • Jibri(Jitsi BRoadcasting Infrastructure):提供一个记录和流式传输一个Jitsi Meet会议的服务。它的工作原理是启动一个在虚拟framebuffer中渲染的Chrome实例,然后用FFmpeg捕获并编码输出。它将在单独的机器上运行,一个Jibri服务只能同时录制一次视频会议,如果在其它会议室正在录制的同时再开户新录制,将返回没有可用设备或设备忙(考虑Jibri池)。可以采用客户端录制,但很消耗CPU导致卡顿。备注:使用之前需要先设置ALSA loopback设备(仅支持Linux)。

 

  • Jicofo(Jitsi Conference Focus):Jitsi Meet中使用的服务器端焦点组件。即一种代理,负责确保一个参与者发送的媒体被分发给会议的所有其他参与者,以便每个人都能有效地听到或看到其他人。它是管理所有正在进行的会议的主要协调实体。当会议开始时,就会创建一个房间,任何知道该房间名称的人都可以进入该房间。

 

  • Jigasi(Jitsi Gateway to SIP):一个链接的服务器端应用程序,允许常规SIP客户端加入Jitsi Video-Bridge主持的Jitsi Meet会议。

 

  • Prosody:XMPP Server,可用做信令(Signalling)服务器。

 

  • Nginx:Web Server

 

  • XMPP MUC(Multi User Chat):基于XMPP的群聊协议。

 

  • Colibri (Conferences with Lightweight Bridging):定义了一个XMPP扩展,允许实时通信客户端发现并与提供会议混合/中继功能的会议桥进行交互。

 

  • SIP(Session Initiation Protocol,会话初始协议):一个基于文本的应用层控制协议,用于创建、修改和释放一个或多个参与者的会话。SIP 是一种源于互联网的IP语音会话控制协议。

 

  • IRC(Internet Relay Chat,因特网中继聊天):RC用户使用特定的用户端聊天软件连接到IRC服务器,通过服务器中继与其他连接到这一服务器上的用户交流。

 

  • Etherpad:一个实时共享与协作的字处理软件。可以邀请一个或多个人访问文档,并在每个人进行添加和编辑时进行观察。

 

  • Jidesha:桌面共享需要用到的插件(Firefox/Chrome),配置较复杂。或者也可以直接采用收费的插件:Jitsi Desktop Sreamer(Chrome)。

 

  • UPnP(Universal Plug and Play,通用即插即用) ,该协议的目标是使家庭网络(数据共享、通信和娱乐)和公司网络中的各种设备能够相互无缝连接,并简化相关网络的实现。UPnP体系允许PC间的点对点连接、网际互连和无线设备。它是一种基于TCP/IPUDPHTTP的分布式、开放体系。

 

  • 缺点:Jitsi用的是SIP和XMPP,编译部署过程过于复杂,依赖库较多,且文档比较少。

Jisti分布式部署示例(单Jitsi-Meet, 多Video-Bridges),如图十三所示。

Jitsi SDK

  • Lib-Jitsi-Meet:JavaScript接口SDK,将Jitsi Meet模块嵌入到自己的应用程序中,用于Web客户端的开发。

https://github.com/jitsi/lib-jitsi-meet

  • Lib-Jitsi:Java接口SDK。用于安全地实时地音视频交流,用于服务器端开发。

https://github.com/jitsi/libjitsi

3.4 小结

对流媒体服务器的选择,没有最好,只有最合适。每个开源实现都有其各自的特点,需要根据自身特点以及项目特点选一个最合适的。

  •  Licode是一个完整的系统,支持分布式集群部署。系统相对复杂,学习周期要长一些。它可以直接布署在生产环境,但是二次开发的灵活性不够。
  • Janus是一个独立的服务,支持的信令协议很丰富,而且支持插件开发,易扩展,对于Linux/C背景的开发者是很不错的选择。如果要做的业务种类比较多,变化比较快,建议选择使用Janus作为流媒体服务器。将你的业务做成一个插件放到Janus上很快就能实现你们的业务需求。架构较复杂,不太适合初学者。
  • Medooze和MediaSoup都是流媒体服务器库,对于需要将流媒体服务器集成到自己产品中的开发者来说,应该选择它们。如果团队能力比较强,可以做底层开发,那么建议使用MediaSoup。因为MediaSoup不关心应用层,它关注的是底层数据如何高效的流转,代码简洁、高效,性能极佳。如果业务变化不大,除了追求性能外,还需要录制、推流之类的功能,那么可以选择使用Medooze,它可以很好的满足你们的需求。
  • Kurento是一个媒体服务框架,可以构建任何类型的后端媒体处理功能:SFU、MCU、Recording、Transcoding、Gateway等。如果你的需求比较复杂,需要做很多集成,那么最好还是使用Kurento。
  • 如果擅长Java,并且只是需要单纯的XMPP信号流的SFU,那么建议使用Jitsi。

四、Jitsi架构

4.1  网络拓扑

如图十四所示。分为二类用户接入:WebRTC和SIP。其中,Web Server可以理解为Nginx + Jitsi Meet。

4.2 技术架构

如图十五所示。可分为访问层、应用层和媒体层。

  1. 访问层(Access Layer):接入端。例如:Web浏览器。
  2. 应用层(Application Layer):内含Jitsi重要组件。例如:Jicofo提供基本信令服务、负载均衡等;Jirecon和Jipopro是负责录制视频相关的功能。
  3. 媒体层(Media Layer):Jitsi Video-Bridge负责中继视频流,是一个选择性转发单元(SFU)。

备注:FreeSwitch是一个开源的电话交换平台,类似一个背靠背的用户代理,用来帮助通信的双方进行实时的语音视频通信。FreeSwitch支持多种通讯技术标准,包括SIP、H.323、IAX2以及GoogleTalk,可以方便的与其他开源的PBX系统进行对接,可以用作交换机引擎、PBX、多媒体网关以及多媒体服务器等。

4.3 事件交互

一个简单示例,如图十六所示。

4.4 分布式方案

如图十七所示。一种示例方案,多区域分布式部署(美国东部/西部、欧洲中部/西部、亚太区域)。

五、Jitsi部署

Jitsi官方开源子项目有100多个,必备项目有5个:Prosody、Jitsi-Meet、Jicofo、Jitsi-Video-Bridge(jvb)、Turn Server。

官方文档提供三种部署方式,具体安装过程请参见官网示例。

1) 快速安装(即打包安装)。

  • Debian 10.x会遇到JDK8安装问题。

2) 基于Docker的安装。

  • 配置复杂。

3) 手工安装(即依次逐个安装)。

  • jitsi-videobridge-xx.zip官网链接已失效。

注意事项

  1. 经安装测试,Windows环境下采用Docker容器方式,需要安装Hyper-V,Win10家庭版会遇到一些问题(例如:没有Hyper-V,容器启动不了等)。
  2. Windows环境下采用VMWare虚拟机安装Debian/Ubuntu的方式,则需要禁用Hyper-V;
  3. 先修改Linux默认来源地址(例如:Debian下的/etc/apt/sources.list)到国内镜像地址(例如:清华/阿里)。
  4. 可切换到root权限(终端输入:sudo -i),再按官网步骤安装。
  5. 终端输入:sudo nautilus,将以界面方式打开root文件夹。

 

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页