上图是server的视频传输并显示到前端的流程。
在之前的硬切割无法满足实际需要的情况下,当前的软切割方案是将 rtsp 流存储为mp4文件,点播时先将已有的mp4文件转码为流,然后通过流分发协议进行视频网页播放,本文主要描述如何解协议,即对流分发协议的选取。
经过反复比较,解协议通用的几种方案如下:
1、将RTSP视频流通过 ffmpeg 切割为 ts 文件和 m3u8 索引文件,在 h5 上直接使用 video.js 标签播放视频
2、将RTSP视频流转换为RTMP视频流,播放方法有:
-
- 使用 http-flv 播放RTMP视频流
- 将RTMP/RTMFP包装为H5, 通过 Java Script wrapper 播放
- 使用 Flashplayer 播放RTMP/RTMFP视频流
3、网页播放 RTSP 视频流
-
- 插件方案(网上有很多,但是该方案被我排除了)
- 无插件方案
- webRTC
- websocket
4、使用 WebAssembly 将 ffmpeg 编译到JS代码中,从而完成FTSP在线播放
以下是对各个协议的对比:
HLS
- 应用层协议,基于HTTP;支持流媒体直播和点播
- 原理:
- 采集推流端将视频流推送到流媒体服务器,服务器将收到的流信息每缓存一段时间封包成新的 ts 文件,同时建立一个m3u8索引文件维护最新几个 ts 片段索引。
- 播放端通过m3u8索引获取最新 ts 视频文件片段播放。客户端获得的不是完整视频流,而是短时长的连续媒体文件。
- 通过HTTP协议传输,不需要考虑防火墙或者代理
- 客户端可以平滑切换码率以适应不同带宽条件下的播放
- 使用兼容H5的浏览器即可播放
- 基于短连接的HTTP,有很大的连接开销
- 延时高
- 编码必须是h264+AAC
- 存储海量小文件
- 播放连续性:两个TS片段可以无缝拼接,播放器可以连续播放;两个MP4文件连续播放会破音和画面中断
- 跳转:如果单个视频较大,想要点击跳转时,如果用MP4格式,HTTP协议,则需要代理服务器支持HTTP range request获取大文件的一部分,性能开销大。如果用 ts 文件,跳转起来则很高效。
- 切片计算:如果使用 ts 文件,实现视频切割需要对视频切点做计算,根据m3u8索引文件算出视频切点再生成新m3u8文件。而如果用MP4,则无需计算直接切割。
- 读写问题:如果使用 ts 文件,则每次接口请求时,都需要生成一个m3u8文件,而且会有海量小文件
RTMP
- 应用层协议,编码器输出的工业标准协议,Adobe私有协议,未完全公开。基本所有编码器都支持RTMP输出。
- 基于TCP的一个协议族,包括:RTMP基本协议/RTMPT/RTMPS/RTMPE 多变种
原理
-
- 从采集推流端到流媒体服务器再到播放器是一条数据流(在我们的项目中有落地文件)
- 将数据流封装成 flv 或者 f4v 通过HTTP提供出去
- 优点:
- 基于TCP长连接,不需要多次建连,稳定性高
- 支持加密(后两个变种)
- 支持长时间播放
- 延迟低(因为是流,对本项目无此影响)
- 协议复杂,冗余字段多,比如三次握手中时间戳的校对
- 有累积延迟——解决:当客户端缓冲区很大时,断开重连
RTSP
- 流媒体协议,视频数据和信令数据分2-3个通道传输
- 原生rtsp进行浏览器播放基本无法兼容,一般要通过协议转换为如下协议才能播放:
- hls
- rtmp
- http
- webrtc
- 缺点:
- 需要转换协议才能播放
- 私有协议
以下是对播放方式的对比:
HTTP-FLV
- HTTP流,没有特定的流,当前互联网音视频平台点播常用,可以封装mp4/flv/f4v
- 优点:
- 性能高,相比HLS没有碎片,分发大文件方便
- 不丢包,低延迟
- 可以使用https加密通道,也无需考虑防火墙问题
- 缺点:
- 移动端浏览器支持很差
- 累积延迟,RTMP协议复杂
- 在浏览器上播放,如果用video.js的话需要flash支持。可以用flv.js做替代方案
H5直接播放HLS
- HTTP, 本质上是对小视频文件索引并播放
- 优点:
- 用户体验好,容易实现
- 缺点:
- 延迟高
WebSocket播放RTMP
- 通过websocket发送MPEG,通过js解析MPEG不断绘制canvas
- 优点:在有GPU的情况下,性能尚可
- 缺点:待更新
RTSP通过WebAssembly编译后的ffmpeg播放
- 待更新
参考文档
http://www.docin.com/p-358292911.html
https://wenku.baidu.com/view/604fce1aa21614791711287c.html
雷霄骅技术博客