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

对于监控行业rtsp在浏览器中播放的问题这些年很多同行朋友都在研究。

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

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发送给浏览器播放延时基本控制在100ms左右好的情况都不到100ms，若在相机端直接把编码器的H264的数据发送出去延时和rtsp基本不相上下。个人比较推荐使用webrtc进行相机视频的播放，真的没有大家想象的那么复杂。

以下给出几个开源的实现。srs网上看到说代码已经实现了，但还没开源可能还得在等几天吧。本人是做C、C++出生，看到互联网的golang很火就用其写了个流媒体协议转换工具。由于刚学golang没几天，碍于面子就不开源了，毕竟是个demo技术含量不高，而且还有很多BUG适合测试。

开源的实现

https://github.com/lulop-k/kurento-rtsp2webrtc   编译可能有点点复杂

https://github.com/ossrs/srs  可以参考4.0.23

https://github.com/srymurphy/ffmpeg2webrtc  我写的一个测试小demo，有兴趣的试试。

 

以下是我的测试图

图片中左边第一个窗口是webrtc点播，第二个是ffmpeg命令行点播，第三个是海康的web页面控件播放，最右面是一个秒表为了方便摄像头对着显示器测试的。