流媒体方案调研汇总

1. 1. 调研思路

1. 调研市场上流媒体实现技术框架, 并了解流媒体相关协议,组件, 筛选出几款流媒体技术框架进行对比研究

2. 进一步研究选择的流媒体技术框架, 研究官方文档, 技术文档, 并部署安装, 简单测试体验

3. 输出调研文档

1. 概念概述
   1. 流媒体

是指将一连串的媒体数据压缩后，经过网络分段发送数据，在网上即时传输影音以供观赏的一种技术与过程，此技术使得数据包得以像流水一样发送；如果不使用此技术，就必须在使用前下载整个媒体文件，这对于实时性要求比较高的场景而言，显然是不现实的，所以流媒体技术为此孕育而生。

传统的视频监控、IPTV，以及这几年兴起的视频直播、网络授课都属于流媒体的范畴，从广义上来讲，视频通话，视频会议也属于流媒体。

1. 1. 流协议

流协议就是在两个通信系统之间传输多媒体文件的一套规则，它定义了视频文件将如何分解为小数据包以及它们在互联网上传输的顺序，RTSP与RTMP是比较常见的流媒体协议。

1. 1. RTSP (Real Time Streaming Protocol, 实时流传输协议)

RTSP,即时串流通讯协议（Real Time Streaming Protocol，RTSP），它是RealNetworks公司协助建立的一个用来传送串流媒体的开放网页标准。RTSP协议是公有协议，有专门的机构维护RTSP协议，一般传输的是ts、mp4格式流。RTSP是基于文本的多媒体播放控制协议。RTSP定义流格式，流数据经由RTP传输；RTSP实时效果非常好，适合视频聊天，视频监控等方向。RTSP虽然实时性最好，但是实现复杂。

1. 1. RTMP (Real Time Messaging Protocol, 实时消息传输协议)

RTMP，实时消息传输协议（Real Time Messaging Protocol，RTMP）。由Adobe 公司提出的私有协议，一般传输的是flv、f4v格式流。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，优势在于低延迟，稳定性高，支持所有摄像头格式，浏览器加载 flash插件就可以直接播放。

1. 1. HLS (HTTP Live Streaming, 自适应码率流媒体传输协议)

HTTP Live Streaming（简称 HLS）是一个基于 HTTP 的视频流协议，由 Apple 公司实现，Mac OS 上的 QuickTime、Safari 以及 iOS 上的 Safari 都能很好的支持 HLS，高版本 Android 也增加了对 HLS 的支持。

HLS 协议本质还是一个个的 HTTP 请求 / 响应，所以适应性很好，不会受到防火墙影响。它也有一个致命的弱点：延迟现象非常明显。如果每个 ts 按照 5 秒来切分，一个 m3u8 放 6 个 ts 索引，那么至少就会带来 30 秒的延迟。

HLS 在 PC 端仅支持safari浏览器，类似chrome浏览器使用HTML5 video标签无法播放 m3u8 格式，可直接采用网上一些比较成熟的方案，如：sewise-player、MediaElement、videojs-contrib-hls、jwplayer。

1. 1. 推流与拉流

推流：把采集阶段封包好的音视频内容传输到服务器的过程。

拉流：服务器已有音视频内容，用指定地址进行拉去的过程。

1.  流媒体框架

目前市场上能够实现流媒体直播与点播的技术框架众多，在这里做一下比较热门的框架的对比，可以根据需求选择合适的框架。

流媒体技术框架包括（选取主流组件）：

1. 监控（第三方摄像头端），这个由用户自行选择，在这里不做对比。
2. 推流端：采用javaCV(安卓和java平台推荐javaCV)、ffmpeg、openCV或者jmf可以很方便的获取到本地摄像头流媒体。
3. 流媒体服务器：

FMS：Flash Media Server (简称FMS)，后更名为Adobe Media Server(简称AMS)，它是最早做流媒体服务器产品，他公司是adobe，是流视频和实时通信领域业界领先的解决方案，该产品可以快速搭建起一套流媒体直播、点播服务器。

SRS：SRS（Simple Rtmp Server）的定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。

1. 拉流端（播放器）：通过flex(flash)播放器或者第三方播放器(videoJS，ckplayer，VideoLAN 等...)调用流媒体服务器的流媒体源解码并播放。

1. 1. FFmpeg + SRS + Http-Flv

基于rtsp,rtmp和http-flv协议实现的流媒体推送方案，ffmpeg作为推流端，srs server作为流媒体服务器，拉流端可以基于http-flv协议实现，可以自己开发网页版（FLV播放器 源码二例 - 走看看），或者下载播放器（恒星播放器-视觉享受 随心而动）。

rtmp作为推流协议，传输稳定，延迟较低，一般在1-3s，非常适合用于直播场景下的推流。

http-flv作为拉流端协议，延迟较低，一般在1-3s，非常适合用于手机APP端拉流。但是使用http-flv协议作为拉流协议，会让流媒体资源缓存在本地客户端，在保密性方面不够好。当网络流量较大时，它也不适合做拉流协议。

 

1. 1. OBS + SRS + VLC

使用obs推流，obs推流使用的是rtmp协议，延迟较低，另外有可操控界面，友好直观；服务器依然是srs server，使用vlc播放器作为收流端，VCL是一个很强大的播放器，支持播放网络串流，使用的也是rtmp协议。

但是此方案视频延迟可能在6s左右，还需做进一步优化配置（更改配置文件srs.conf文件即可），优化后延迟在2s左右。

 

1. 1. RTMP + SRS + webRTC

rtmp推流可以使用ffmpeg，延迟低。

拉流使用webRTC，webRTC起初用于视频会议等及时通讯，现在越来越成熟，应用也越多，正常延迟为1秒之内。webRTC可以实现浏览器上实现无插件的视频通话，该技术也可以用于实现低延时的视频直播。目前业界也有很多基于webrtc的应用和产品，但是很多局限于视频聊天等低延时交互式场景，在视频监控领域，目前还尚未流行。

由于vcl不支持webRTC格式串流，所以直接用控制台自动的webRTC播放器查看。

1.  功能模块整理

根据调研的流媒体技术框架，分析总结出流媒体框架通用功能模块，及其功能定义。

1. 1. 流媒体处理过程
2. 采集：通过摄像机，网络摄像头和麦克风等设备直接采集音视频数据。
3. 编码：将原音视频进行压缩处理，降低原音视频的大小来提高视频的存储和传输效率。
4. 推流：将音视频数据使用传输协议进行封装，变成流数据，并推送到流媒体服务器。
5. 转码：服务器对流数据进行不同格式的编码转换，以此来适配不同网络和分辨率的终端设备的播放。
6. 拉流：通过客户端的播放器获取从服务器分发过来的码流。
7. 解码：编码的逆过程，从压缩编码过的音视频数据中提取还原为原始数据。

1. 1. 流程管理
2. 流媒体服务器安装（docker安装或源码安装）
3. 推流组件安装
4. 拉流端播放器安装（开发）
5. 推流
6. 拉流

1. 总结

目前市场上可供选择的流媒体技术框架有很多，可供选择的技术组件也有很多，但无非都是依赖几个共同的推流与拉流协议来完成的。所以，像推流组件与流媒体服务器，拉流组件都可以有很多选择，并且他们也可以相互组合。例如使用srs作为流媒体服务器，既可以使用ffmpeg推流，也可以使用obs推流。可以使用vlc拉流，也可以使用别的播放器拉流。关键在于看他们所支持的流媒体协议。目前来看，rtsp，rtmp协议性能较好，延迟较低，一般在1-3s，而且还可以优化配置，进一步减少延迟；而hls协议则延迟较高，优化后效果也不是很理想，所以不建议选取使用hls协议的流媒体组件和框架。

另外，本次调研的方案及其组件都是开源的，所以没有预算成本的考虑，只会设计到各个流媒体组件的可操作性跟操作难度考虑，比如推流组件ffmpeg是用命令行来操作的，而obs则有可操作化的页面。有的拉流端是播放器，需要下载，有的拉流端是网页版播放器，还有的可以开发制作网页版播放器，总的来说，差异不是很大，实现难度也没有太大差别。

以上方案目前只是调研阶段，如需推进使用，还需进一步测试验证。