先说下结论，我们目前选型优先级为srs, nginx-rtmp，easydarwin。 目前由于定制优先，选择了easydarwin进行定制，srs作为备选。

1 背景说明

这里的需求为某公安视频监控项目建设，需要一个流媒体服务器支持视频直播与点播。

1.1 功能需求

直接需求为摄像头监控。

1.多路实时视频，即同屏展示多路摄像头实时视频。

2.多路录像视频，即同屏展示多路摄像头录像视频

后续需求

1.直播，将主播视频同步给多终端。

2.视频会议*，将多人视频同步给各用户。

1.2 性能指标

1.多路实时视频，百路，常规 5*5；

总路数在带宽满足的情况，可动态扩容。并发最小 500 路。

2.多路录像视频，百路，常规 5*5；

总路数在带宽满足的情况，可动态扩容。并发最小 500 路。

3.直播，500，常规 100；

4.视频会议，100，常规 30；

2 基础概念

2.1 RTP

实时传输协议 – 维基百科，自由的百科全书

**实时传输协议（Real-time Transport Protocol 或简写 RTP）**是一个网络传输协议，它是由 IETF 的多媒体传输工作小组 1996 年在 RFC 1889 中公布的。

RTP 协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP 协议常用于流媒体系统（配合 RTSP 协议），视频会议和一键通（Push to Talk）系统（配合 H.323 或 SIP），使它成为 IP 电话产业的技术基础。RTP 协议和 RTP 控制协议 RTCP 一起使用，而且它是创建在 **UDP **协议上的。

2.2 RTMP

实时消息协议 – 维基百科，自由的百科全书

**实时消息协议（英语：Real-Time Messaging Protocol，缩写 RTMP）**也称实时消息传输协议，是最初由 Macromedia 为通过互联网在 Flash 播放器与一个服务器之间传输流媒体音频、视频和数据而开发的一个专有协议。Macromedia 后被 Adobe Systems 收购，该协议也已发布了不完整的规范供公众使用。

RTMP 协议有许多变种：

默认使用 TCP 端口 1935 的纯粹（plain）协议。


RTMPS

，通过一个 TLS/SSL 连接传输 RTMP。


RTMPE

，使用 Adobe 自有安全机制加密的 RTMP。虽然实现的细节为专有，但该机制使用行业标准的密码学原函数。


RTMPT

，用 HTTP 封装以穿透防火墙。RTMPT 通常在 TCP 通信端口 80 和 443 上使用明文请求来绕过大多数的公司流量过滤。封装的会话中可能携带纯粹的 RTMP、RTMPS 或 RTMPE 数据包。


RTMFP

, 使用 UDP 而非 TCP 的 RTMP，取代 RTMP Chunk Stream。Adobe Systems 开发了安全的实时媒体流协议包，可以让最终用户直接地相互连接（P2P）。

2.3 WebRTC

https://webrtc.org/

WebRTC is a free, open project

that provides browsers and mobile applications with

Real-Time Communications (RTC)

capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.


Our mission

: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by

Google

,

Mozilla

and

Opera

, amongst others.

支持的浏览器和平台：

• Chrome
• Firefox
• Opera
• Android
• iOS

特点：

• 基于浏览器，且主流浏览器都支持，跨平台能力强
• 默认 P2P，但是需要 TURN 服务器作为 fallback
• 自适应码率
  • 
    webrtc 视频编码之 h264 自动调节分辨率 — newrtc
    
  • 
    webm – Does WebRTC support Adaptive Bitrate Streaming for video? – Stack Overflow
    

相关资料：

• 
  2013 Google I/O 大会上WebRTC的幻灯片
  
• 
  Getting Started with WebRTC – Sam Dutton
  
• 
  WebRTC in the real world: STUN, TURN and signaling – Sam Dutton
  
• 
  IETF Real-Time Communication in WEB-browsers (rtcweb) Working Group
  
• 
  RFC7742 – WebRTC Video Processing and Codec Requirements
  

2.4 HLS

HTTP Live Streaming – 维基百科，自由的百科全书

HTTP Live Streaming

（缩写是 HLS）是一个由苹果公司提出的基于 HTTP 的流媒体网络传输协议。它的工作原理是把整个流分成一个个小的基于 HTTP 的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的 extended M3U (m3u8) playlist 文件，用于寻找可用的媒体流。

HLS 只请求基本的 HTTP 报文，与实时传输协议（RTP）不同，HLS 可以穿过任何允许 HTTP 数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络（CDN）来传输媒体流。

2017 年 8 月，

RFC 8216

发布，描述了 HLS 协议第 7 版的定义

RFC 8216

2.5 流媒体服务器架构

https://www.cnblogs.com/cnhk19/articles/11641895.html

https://www.cnblogs.com/yiyi17/p/12076657.html

• WebRTC：名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6 月 1 日开源；
• MCU (MultiPoint Control Unit) MCU 是传统视频会议系统中的核心控制单元，在 WebRTC 的系统实现中， 适合于多人音视频通话场景，MCU 可以对接收到的多路流进行转码和混合，并向每个终端输出单路流。
• SFU 的全称是：Selective Forwarding Unit（选择性转发单元），是一种通过服务器来路由和转发 WebRTC 客户端音视频数据流的方法。如果你计划在 WebRTC 中有多个参与者，那么最终可能会使用选择性转发单元(SFU)；

2.6 推流

推流，指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。“推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有 RTSP、RTMP、HLS 等，使用 RTMP 传输的延时通常在 1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。

2.7 拉流

拉流是指服务器已有直播内容，根据协议类型（如 RTMP、RTP、RTSP、HTTP 等），与服务器建立连接并接收数据，进行拉取的过程。拉流端的核心处理在播放器端的解码和渲染，在互动直播中还需集成聊天室、点赞和礼物系统等功能。

拉流端现在支持 RTMP、HLS、HDL（HTTP-FLV）三种协议，其中，在网络稳定的情况下，对于 HDL 协议的延时控制可达 1s，完全满足互动直播的业务需求。RTMP 是 Adobe 的专利协议，开源软件和开源库都支持的比较好，延时一般在 1-3 秒。HLS 是苹果提出的基于 HTTP 的流媒体传输协议，优先是跨平台性比较好，HTML5 可以直接打开播放，移动端兼容性良好，但是缺点是延迟比较高。

3 开源方案

基于以上了解，架构上我们倾向于 SFU，配合 Simulcast 或者 SVC 模式。

另外，面向 RTSP 安防领域 与 RTMP,WEBRTC 视频会议直播领域的方案是不太一样的，需要区别对待。目前大部分开源方案为面向视频会议直播领域的，极少部分为针对安防领域，如 easydarwin。可以通过 RTSP 转码 RTMP 来兼容，但是会消耗大量 CPU，并产生延迟。

经过调研发现，目前主流的开源方案普遍采用 C,C++等语言，除了语言的高性能外，更关键的是完备成熟的处理库；后起之秀 GO 也勉强占了一席之地，但成熟商用的很少，虽然语言解决了 C，C++内存的问题，有方便的 go-routine，但是很多情况还是要调用 C++的库，需要追赶的实在太多；JAVA 作为目前项目用的最多的语言，在流媒体的存在感很弱，虽然有 Red5 Pro 这种制霸级的项目，但是开源版却很弱，基本忽略。

初始调研的核心指标，可靠，性能，可定制；可靠性能基本要靠实际项目来检验，可定制主要从预研层面来考量。根据上面语言层面的分析，C/C++搞不定放弃，Java 没有好的放弃，只剩下 GO，GO 相关的靠谱开源项目只有 easydarwin，monibuca，livego 等太新了，风险太多。

详细看 easydarwin，发现这个项目 go 版本为 18 年 11 月发布，为第一个版本，之前也是 C++版本，本来采用这个开源项目的就不多，再加上是第一个 go 版本，风险也很大。这个项目宣传做的不错，但是使用着实不多，仔细搜了下，发现这个项目为国内一家公司维护，主营业务为周边

产品，也就是说了除了流媒体服务开源外，其他大部分为收费。再加上这唯一开源的流媒体服务是个实验版，增加了我不太想用这个的想法。另外吐槽下，开源项目连个开源协议都没有。

http://www.qianqian51.cn/?mod=pad&act=view&id=17

到此，JAVA,GO 基本排除，也就不用太纠结定制开发了，随大流找一款用的最多的开源拿项目即可。这时进入视野的包括 srs, nginx-rtmp，这两个是用的比较多的，github 基本都达到 9k star。这两个都是出自大牛之手。

目前我们比较倾向于 srs，出自阿里云大牛，持续更新，性能达到nginx-rtmp两倍。

实际目前初步采用easydarwin go版本，自己进行定制优化。

详细资料如下：

4 参考资料

视频监控摄像头的互联网化实践思路

https://zhuanlan.zhihu.com/p/141849029

几种开源的媒体服务器对比

https://juejin.im/entry/5aeed7fff265da0b78686960

移动视频会议开源框架

http://www.qianqian51.cn/?mod=pad&act=view&id=17

开源流媒体服务器的选择，利与弊的权衡

https://zhuanlan.zhihu.com/p/73461234

视频直播技术（四）：流媒体服务器搭建

https://www.cnblogs.com/renhui/p/8471641.html

https://github.com/GB28181