上图是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 视频流

插件方案（网上有很多，但是该方案被我排除了）无插件方案webRTCwebsocket

4、使用 WebAssembly 将 ffmpeg 编译到JS代码中，从而完成FTSP在线播放

以下是对各个协议的对比：

HLS应用层协议，基于HTTP；支持流媒体直播和点播原理：采集推流端将视频流推送到流媒体服务器，服务器将收到的流信息每缓存一段时间封包成新的 ts 文件，同时建立一个m3u8索引文件维护最新几个 ts 片段索引。播放端通过m3u8索引获取最新 ts 视频文件片段播放。客户端获得的不是完整视频流，而是短时长的连续媒体文件。优点：通过HTTP协议传输，不需要考虑防火墙或者代理客户端可以平滑切换码率以适应不同带宽条件下的播放使用兼容H5的浏览器即可播放缺点：基于短连接的HTTP，有很大的连接开销延时高编码必须是h264+AAC存储海量小文件在HTTP下，TS和MP4相比的优缺点：播放连续性：两个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进行浏览器播放基本无法兼容，一般要通过协议转换为如下协议才能播放：hlsrtmphttpwebrtc

缺点：需要转换协议才能播放私有协议

以下是对播放方式的对比：

HTTP-FLVHTTP流，没有特定的流，当前互联网音视频平台点播常用，可以封装mp4/flv/f4v优点：性能高，相比HLS没有碎片，分发大文件方便不丢包，低延迟可以使用https加密通道，也无需考虑防火墙问题

缺点：移动端浏览器支持很差累积延迟，RTMP协议复杂在浏览器上播放，如果用video.js的话需要flash支持。可以用flv.js做替代方案H5直接播放HLSHTTP， 本质上是对小视频文件索引并播放优点：用户体验好，容易实现缺点：延迟高WebSocket播放RTMP通过websocket发送MPEG，通过js解析MPEG不断绘制canvas优点：在有GPU的情况下，性能尚可缺点：待更新RTSP通过WebAssembly编译后的ffmpeg播放待更新参考文档

雷霄骅技术博客