流媒体服务器概览

摘要

本文介绍了Top 10的开源流媒体服务器及选型建议。

术语

媒体：音频、视频、文本等信息表示形式的统称。

串流：表示将媒体数据串行化发送，比如将PC上的游戏画面串流到Pico、Oculus Quest之类的VR设备，实现沉浸式的游戏体验。

媒体流：一个mp4文件可以被串流化成一个媒体流（Media Stream)。

轨：一个媒体流中可包含零到多个音频轨（Audio Track）和视频轨（Video Track）。媒体播放器播放时可根据各个轨的媒体样本（Media Sample）的呈现时间戳（pts）进行时钟同步。

流媒体：以串流化的方式在网络中传送的音频、视频媒体形式。

流媒体服务器：在网络上提供媒体数据串流化服务的程序，一般支持实时媒体源直播（Live Streaming)和历史媒体源点播（VOD）两种形式。通过配置不同的串流化策略，可以将直播和点播功能统一设计，让用户只通过点击时间进度条即可在直播和点播之间自然切换。

流媒体技术历史悠久，风靡一时的流媒体服务器多不胜数。本文仅描述采用C/C++语言开发的、影响力排名前十的开源流媒体服务器。根据是否支持WebRTC，作者将流媒体服务器划分为两大类：

古典流媒体服务器：支持RTMP或RTSP/RTP/RTCP协议。

现代流媒体服务器：支持WebRTC。

古典流媒体服务器

1. live555：实现了RTSP/RTP/RTCP协议。支持mkv、mp4容器文件点播。优点是简单，缺点是支持的协议少，性能差。作者提供的Windows版源码仓库：https://github.com/bigfacecat2014/live555.git。
2. Darwin Streaming Server：Apple公司提供的开源实时流媒体服务器程序，可以运行在Windows、Mac OS X、Linux操作系统上。支持RTSP/RTP/RTCP协议。源码仓库：https://github.com/macosforge/dss
3. Nginx-rtmp-module：基于nginx开发的rtmp协议流媒体服务模块。其优点是支持RTMP和HLS，性能有保证，缺点是只支持RTMP和HLS。源码仓库：https://github.com/arut/nginx-rtmp-module.git

 现代流媒体服务器

1.ZLMediaKit：一个基于C++11的高性能运营级流媒体服务框架，项目特点如下：

（1）基于C++11开发，避免使用裸指针，代码稳定可靠，性能优越。

（2）支持多种协议(RTSP/RTMP/HLS/HTTP-FLV/WebSocket-FLV/GB28181/HTTP-TS/WebSocket-TS/HTTP-fMP4/WebSocket-fMP4/MP4/WebRTC),支持协议互转。

（3）使用多路复用/多线程/异步网络IO模式开发，并发性能优越，支持海量客户端连接。

（4）代码经过长期大量的稳定性、性能测试，已经在线上商用验证已久。

（5）支持linux、macos、ios、android、windows全平台。

（6）支持x86、arm、risc-v、mips、龙芯、申威等指令集平台。

（7）支持画面秒开、极低延时(500毫秒内，最低可达100毫秒)。

（8）提供完善的标准C API,可以作SDK用，或供其他语言调用。

（9）提供完整的MediaServer服务器，可以免开发直接部署为商用服务器。

（10）提供完善的restful api以及web hook，支持丰富的业务逻辑。

（11）打通了视频监控协议栈与直播协议栈，对RTSP/RTMP支持都很完善。

（12）全面支持H265/H264/AAC/G711/OPUS。

（13）功能完善，支持集群、按需转协议、按需推拉流、先播后推、断连续推等功能。

（14）极致性能，单机10W级别播放器，100Gb/s级别io带宽能力。

（15）极致体验，独家特性丰富。

（16）全面支持ipv6网络

2.SRS：采用协程特性实现的各种网络协议，优点是可以用同步的风格编写出具备异步特性的代码。SRS坚持使用C++98的部分特性，采用单线程多协程方式实现高并发，代码稳定性和可读性较高，性能出色。

3.janus-gateway：WebRTC流媒体服务器，采用C语言实现，支持 Linux/macOS下编译、部署，不支持 Windows。优点是采用了插件方案。源码仓库：https://github.com/meetecho/janus-gateway

4.Mediasoup：WebRTC流媒体服务器，底层采用C++语言实现，使用 libuv 作为异步I/O事件处理库，采用SFU多对多通信模式。优点是简洁、高效，缺点是功能单一。源码仓库：https://github.com/versatica/mediasoup/ 

5.Medooze：基于Node.js生态，底层的媒体转发功能采用C++开发，业务层用js开发。适合擅长js语言且想避开C++语言的开发者。

6.Licode：由C++和Node.js语言实现。它是一套完整且高度复杂的音视频会议系统，既可做SFU，也可做MCU。

7.OWT：是Licode的一个变种。

8.Jitis：底层模块采用C/C++语言编写，业务层主要采用java语言编写（也有js、lua）。适合擅长Java的同学使用。

9.Kurento：采用C++语言开发，已经维护了多年。

ZLMediaKit和SRS对比

从三个不同维度对比分析如下：

1. 性能：ZLMediaKit和SRS在性能方面都有很好的表现，但是具体性能取决于应用场景和硬件环境。一般来说，SRS的单线程并发性能高于 ZLMediaKit，但是ZLMediaKit由于采用了单进程多线程并发设计，在单机内无进程间通信的开销，在单进程高并发时有明显的性能优势。
2. 功能：ZLMediaKit和SRS都提供了丰富的功能和API，例如音视频采集、编码、解码、转码、推流、拉流、录制、截图、水印、直播流分发等，可以满足各种流媒体应用场景的需求。ZLMediaKit支持在Windows和Linux系统上原生编译和运行。SRS仅支持在Linux系统上原生编译和运行，SRS在Windows上需要借助Linux仿真环境编译和运行。ZLMediaKit具备极强的跨平台能力和丰富的独家特性。
3. 易用性：ZLMediaKit和SRS都需要一定的技术经验和学习成本才能使用和扩展，但是ZLMediaKit的API更加友好和易用，对于C++开发者来说可能更容易上手一些。

综上所述，ZLMediaKit和SRS都是非常优秀的流媒体服务器，选择哪一个取决于你的偏好。

如果你喜欢C++11标准、多线程并发和异步回调风格的编程范式，就选择ZLMediaKit。

如果你喜欢C++98标准、单线程多协程并发和同步风格的编程范式，就选择SRS。