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

时间:2024-04-05 16:26:24

对于监控行业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  webrtc代码还未加进来,等等会有的

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

 

以下是我的测试图

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

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