需求分析
视频流媒体监控行业已经进入互联网时代，浏览器承载了绝大多数的互联网访问流量，目前在网页上播RTSP流的普遍做法是将RTSP转成互联网直播协议RTMP或者HLS；而RTMP协议播放需要Flash插件，且其衍生的FLV或者HLS协议延迟很大（2s以上） ，根本达不到视频流媒体传输低延迟的要求。
早年风靡一时的互联网直播RTMP协议，只有flash浏览器插件播放器才能支持，而Flash不支持RTSP，以后估计也不会支持，而FLASH插件也已经被浏览器厂商淘汰；
那么我们可以自己做浏览器插件播放RTSP，通过npapi、ppapi插件，IE用的ocx插件就可以把播放器可执行程序做成插件给浏览器调用；但是，兼容性太差了，开发成本过高。在PC web兼容性上面，目前最好的方案是flash或者H5，在手机 web/微信兼容上面，毫无疑问，H5是唯一选择；
解决方案
如何实现解决上述需求中的几点问题，解决方案如下：
通过H5直接播放RTSP协议
在PC端通过流媒体输出兼容性强的RTSP协议，通过WEBSOCKET直接和H5交互直接播放RTSP协议，那么以上问题就迎刃而解了，即保证了低延时又能直接网页端无插件播放，简单高效；同时同步输出：rtmp/hls/http-flv多种码流，增加前端的兼容适配，就能完美地达到想要的方案，总结来说，需要通过以下几个步骤：
RTSP拉流；
音视频转码（可选）；
流媒体服务器RTSP转发+WEBSOCKET代理；
流媒体服务器多协议转发RTMP/HTTP-FLV/HLS/WS-FLV；
前端H5无插件取流播放；
技术实现
RTSP拉流
目前市面上能非常兼容地拉取各个厂家的RTSP流的方案总结来说有两种：
Live555
Live555取流实时性高，但是兼容性差，对某些小众厂家的RTSP流或者标准性较差的RTSP流可能存在拉不到流的问题；
FFmpeg
FFmpeg拉流稳定性高，兼容性强，实时性相对较低，我们通常可以通过调整参数来提高实时性。
当然，两种都能比较不错地请求获取到各个厂家的摄像机码流，但从兼容性、稳定性可靠性、以及可操作的灵活角度上来说，FFmpeg更胜一筹，
没有绝对，根据需求，也许您就只需要接入某两款特定类型的摄像机呢，怎么适合现场需求怎么来；
2.音视频转码（H.265转H.264，音频转AAC）
由于目前WEB前端H5的支持上，对H264的支持更好一些，比如：H264支持硬件解码，解码效率更高；而H265只支持软解吗，解码效率相对较低；所以，我们需要将各种视频格式：H.265、MJPEG、MPEG4转成H.264再转发给H5播放，各种音频格式：G.711A/U、G.726，都统一转码成AAC格式，同样的道理，H5对AAC支持更好一些；而音视频转码，业界公认的神奇当然是FFmpeg。
3.流媒体服务器RTSP转发+WEBSOCKET代理
SkeyeSMS支持RTSP转发流媒体服务，我们参考Live555的轻量级RTSPServer流媒体服务设计思想，充分吸收其超低延迟的特点，在此基础上设计多线程分发策略，提高RTSP流媒体分发并发能力和分发效率，弥补Live555单线程分发的并发不足的缺陷。同时，增加WEBSocket代理算法策略，在不影响原有RTSPServer分发策略的基础上共用一个分发缓存队列，建立和H5交互的高效分发通道，达到页面多并发无插件播放RTSP的效果。
关于时间戳调优上，部分监控厂商（大华、雄迈等）的摄像机，其出流的时间戳是极其不均匀的，这就会导致流媒体分发的流经常会出现快放、慢放、卡顿缓冲加载的现象，所以就需要在流媒体分发时对时间戳进行一次均匀化，这一点上可以参考的ffmpeg的-re命令的方案，对时间戳进行了优化，保证均匀播放；
4.流媒体服务器多协议转发RTMP/FLV/HLS
这里说到的RTMP服务器有几种输出协议：
* rtmp
* hls
* http-flv
* ws-flv
liveweb流媒体服务参考nginx-rtmp-module流媒体rtmp转发服务，在此基础上开发 了对 http-flv和ws-flv协议的支持，剔除了其RTMP推流模块，以免无端增加流转发延迟，并优化提高流媒体转发的效率，实现高效、稳定、高并发的多流媒体协议分发；
5.前端兼容取流播放
liveweb流媒体前端采用业界广泛使用的VUE+elementUI先进的前端框架，能响应式地接受各种不同平台终端的请求，为PC web、手机 web、微信分配从网络摄像机流前端获取RTSP并通过liveweb媒体服务器转发rtsp、rtmp、hls、http-flv、ws-flv等直播流；
