rtsp 通过webrtc方案进行浏览器播放

根据实现原理可分为两大类

1.原生rtsp协议播放
曾经我们使用OCX，IE浏览器的插件形式来实现可以说性能及延时都符合要求。缺陷在于只支持IE，在火狐和谷歌等浏览器下却不得不使用另一套API实现，好在国外有一个开源项目http://www.firebreath.org/ 支持多浏览器插件，曾经可是神器般存在写控件不用再纠结各浏览器之间接口等问题，可现在谷歌和火狐更新后之前的插件机制都已不能用。稳定的始终是IE的ocx方式，现如今ocx方式还在国内各银行金融领域使用。

2.协议转换
2.1 hls 协议 后台通过ffmpeg或者其他服务将rtsp协议转换成hls协议给前端页面，前端页面通过hls播放器进行播放，后台部署简单，缺点延时过高
2.2 rtmp协议 同hls方式进行协议转换可利用浏览器的adobe flash player进行无插件播放，缺陷也在延时方面 延时在秒级，若播放器与服务端采用自研或许可将延时降低到300-500ms左右，不过那样的话无插件基本也是空谈了
2.3 http协议   后台进行转码将rtp负载的码流转换为浏览器支持的编码格式或者进行切片发送，后台只需一个好点的http服务器和一个ffmpeg命令即可，延时方面几乎也是秒级的，要降低延时主要在解码编码方面做优化或者对切片文件进行调整。
2.4 websocket协议  后台假设websocket服务 通过将rtp负载的数据包解复用后打包成切片文件发送与http协议方式类似主要在传输协议上不同与http方式在传输上占有一定优势

2.5 webrtc协议  同样是协议转换，但现在浏览器对webrtc的支持良好，特别是在H264编码方面几个主流的浏览器都已经支持了。webrtc使用srtp进行媒体数据的传输，那么我们只需要将rtp中的负载数据通过webrtc通道发送给浏览器，而浏览器端只需要通过video标签播放即可，技术上的复杂点主要在于webrtc和rtsp之间转换上，实际上网上也有不少开源代码已放出。对于做流媒体这块的同行来说并没有大家想象的那么复杂。webrtc 谷歌的源码过于庞大基本把流媒体行业的技术大部分覆盖了，会让很多近几年才加入流媒体行业的人来说觉得门槛很高。我测试时rtsp通过webrtc发送给浏览器播放4M以内的码率延时基本控制在100ms左右，好的情况都不到50ms，若在相机端直接把编码器的H264的数据发送出去延时和rtsp基本不相上下。个人比较推荐使用webrtc进行相机视频的播放。