在Chrome、Firefox等高版本浏览器中实现低延迟播放海康、大华RTSP

1、背景

        如今处处是摄像头的时代，随着带宽的不断提速和智能手机的普及催生出火热的网络直播行业，新冠病毒的大流行又使网络视频会议系统成为商务会议的必然选择，所以RTSP实时视频流播放及处理再也不局限于安防行业。在如道路、工厂、楼宇、学校、港口、农场、景区等场景实施的信息化系统中，已基本全采用B/S架构，迫切须要在浏览器中嵌入多路摄像头RTSP流的超低延迟(小于500毫秒)播放功能，而在IE及Chrome 49如下版本等浏览器中，采用ActiveX控件或NPAPI插件便可实现。然而美好老是短暂的，从2015年开始Chrome及Firefox等浏览器纷纷取消了NPAPI插件的支持，而IE又在与Chrome及Firefox等浏览器竞争的过程当中不断被用户抛弃，到如今市场份额已降到可怜的个位数。微软在几经折腾后，索性也拥抱Chromium内核推出Edge新版来杀死本身的IE，以挽救本身在浏览器这块朝不保夕的江湖地位。

        在Chrome、Edge、Firefox等当前主流的高版本浏览器中，即便是HTML5标准的Video也并未对RTSP流播放提供原生支持，从而致使如何在当前主流的浏览器中实现低延迟、低成本并可同时播放多路RTSP成为了一个重大技术难题。这几年国内外的技术专家通过不断研究总结，造成一些闭源或开源、收费或免费的方案，但多数时候没法彻底知足客户的实际需求。

2、现有方案

在浏览器中实现播放RTSP实时视频流，大致上有以下几个方案：

• 浏览器插件方案

        此方案主要适用于在IE及Chrome 49如下版本的浏览器，在2015年前是绝对主流的选择。使用ActiveX播放控件或NPAPI播放插件实际调用的是本地原生程序进行直接播放，从而可充分利用本机的硬件加速能力，可实现满意的多路低成本、低延迟播放效果。通常使用VLC这个免费开源的跨平台多媒体播放器，IE、Chrome、Firefox等浏览器分别有对应的播放插件，对移动端支持也很是好。此方案很是灵活，能够方便的对接各品牌的视频流，也能够很容易实现截图和录像功能。缺点是须要额外安装VLC软件，对个别明确规定不能用插件的场景不太适用。摄像头厂家通常也会提供适配的播放插件，好比海康威视提供的播放控件，是和本身的DSS系统捆绑使用的。

• 先转码再转流方案

        此方案须要架设一个或多个视频流转码服务器，先在服务器上对RTSP流用ffmpeg进行转码串流成RTMP，而后前端使用VideoJS再调用Adobe Flash Player进行播放，然而2020年末开始基于Chromium内核的全部浏览器就完全取消对Adobe Flash Player的支持，VideoJS失效。不过幸亏还有开源的替代播放方案flv.js(https://github.com/bilibili/flv.js)工做原理是要求在服务端先把RTSP视频流转换为flv后用Web Socket或WebRTC推送到前端，前端收到后再转换为Video所支持的MP4后播放，这就致使RTSP视频流，须要通过2次转码才播放，画面延迟时间大幅度增长，保守估计延迟至少也是2-3秒级别了。何况若是有多路视频流时，服务器端转码和转流对CPU、内存、网络带宽的压力大幅度增长，长期使用成本很高。此方案要求浏览器支持流媒体扩展特性(MSE)，且没法利用本机硬件加速实现解码和渲染。优势是可兼容移动端网页播放。

        此方案在国内有TSINGSEE的免插件EasyPlayer RTSP播放器，项目地址是https://github.com/tsingsee/EasyPlayer和linkingvision的免插件播放器H5stream，项目地址是https://github.com/linkingvision/h5stream等。

• 先转流再转码方案

        此方案的典型表明是Streamedian公司的免插件播放器Html5 RTSP Player，项目地址https://github.com/Streamedian/html5_rtsp_player。此方案须要架设一个Web Socket的视频流转发服务器，前端链接到此服务器后，服务端不断把RTSP视频流经过Web Socket不断转发给前端的JS处理库，JS处理库再把视频流转换为Video所支持的MP4后播放。此方案不支持IE浏览器，最大的问题是画面延迟达数秒，首屏内容显示慢，并且没法利用本机硬件加速实现解码和渲染，CPU占用高，播放时有卡顿现象，体验比较差。另外没法实现本地自动截图、录像等操做。此方案一样要求浏览器支持流媒体扩展特性(MSE)，对延迟不敏感的单源播放尚可，多路播放就只能洗洗睡了，另外根据一些用户的反馈，对各品牌摄像头的兼容性也不太友好，做为商业用途使用是不可行的。

• 扩展程序方案

        此方案典型表明是基于Chrome浏览器的Native Client（NaCl）和Portable Native Client（PNaCl）技术实现开源播放器VXG RTSP Player，项目地址是https://git.code.sf.net/p/rtsp-player-chrome/code rtsp-player-chrome-code。此方案很显然不适用于IE和Firefox等浏览器，也不适用于49版之前的Chrome 浏览器。VXG RTSP Player是Chrome浏览器的扩展程序，对国内客户来讲，因为谷歌服务器在墙外，想要大规模自主可控部署是不现实的。另外最关键的是谷歌已官方宣布，2021年6月终止对NaCl，PNaCl和PPAPI API的支持，于是此方案也无继续探讨的必要。

• 双内核方案

        此方案典型实现是采用Chrome浏览器上的扩展程序IETab来实现，官方网站是https://www.ietab.net，经过在Chrome标签页界面覆盖加载显示一个IE内核渲染的网页，此网页再调用好比VLC的开源ActiveX多媒体播放控件实现。此方案和方案4同样，存在大规模自主可控部署难问题。另外和上面的浏览器插件方案相似，须要在播放终端电脑中下载运行IEHelpTab.exe客户端程序，对一些高安全要求无插件播放的场景来讲不适用。最大的问题是在Chrome网页中对播放控件的控制很难实现，只有网页和播放控件都是在IE内核环境下才能够，而IE对当前一些新技术和前端主流框架的兼容已经不行了，何况IE对运行和下载安装ActiveX控件常常弹出警告，用户体验不好。

• Wasm方案

        此方案采用的是高版本浏览器所支持的一种方便把更复杂的原生应用直接搬进 Web 的标准技术，然而对浏览器的兼容存在很大问题，IE确定是不支持的，低版本的Chrome及Firefox等浏览器也不支持Wasm，具体兼容性可看这里https://caniuse.com/wasm。实现的基本思路就是把RTSP视频流经过ffmpeg的Wasm版软解码成Video所支持的MP4后播放，因为Wasm不支持硬件解码，对多路同时播放来讲，CPU和内存占用会比较高，性能有很大瓶颈。此方案有时应用在须要支持H265编码的场景，一样要求浏览器支持流媒体扩展特性(MSE)。因为存在诸多兼容性问题，此方案实际应用的案例较少。

3、改进方案

        经过上述总结的现有技术方案能够看出，想要在浏览器中实现低延迟、低成本的多路RTSP同时播放，只有作到不转码直接播放和充分利用终端的硬件加速这两个核心要求才能办到，这就只能采用插件方案。核心就在于如何在浏览器中实现一个统一的不依赖浏览器自己扩展技术的插件系统，同时必须让改进方案对各品牌及各版本浏览器有比较好的兼容能力才具备较大的实用价值。因此改进方案基本思路就是要在浏览器网页中指定位置和大小，实现一个内嵌到网页中显示的播放窗口，这个内嵌播放窗口前端还必须可对其进行控制，并且播放窗口必须跟随浏览器窗口的移动和缩放、网页滚动、标签页切换、关闭等操做进行自动联动。这就要求播放窗口必须是本地程序，最好用高性能的C++语言来实现，这样还可充分利用终端的硬件加速能力。这个播放窗口同时提供Web Socket的服务端和JSON打包的命令解析执行模块，前端就能够经过Web Socket链接后发送JSON打包的控制命令实现控制播放窗口。

        目前本公司通过攻城狮的艰苦技术攻关，成功研发出采用此思路实现的VLC网页播放小程序软件并成功在一些客户现场实施，此小程序基于PluginOK中间件(https://github.com/wangzuohuai/WebRunLocal)，提供了一个统一的不依赖浏览器自己扩展技术的插件系统，能实现当前主流浏览器的全兼容，包括低版本的Chrome和IE浏览器；并且对插件的下载和安装提供了相似ActiveX控件的机制，去掉了一些影响用户体验的告警并附加了调用方安全验证机制。而这个播放窗口程序也提供了比较好的范例实现，其具体调用方法能够参考这里的说明：VLC网页小程序开发接口，难能难得的是在这个播放窗口还直接实现了多路RTSP的同时播放支持，可点选切换播放窗口焦点和全屏播放。据了解，此方案已经成功在多个客户现场完成实施并取得了良好的效果，得到了客户的一致好评，毕竟能实现低延迟、低成本的同时播放是硬道理。下面是播放效果视频展现：

VLC网页播放小程序效果演示

某视频监控大厂最近也发布了此思路实现的版本，不过通过测试发现，不支持Firefox高版本浏览器不说，其播放窗口程序框架采用的是臃肿的QT来实现的，看上去播放窗口只是模拟显示的效果而不是真正内嵌到浏览器窗口中的，致使和浏览器的联动效果比较差，插件包也很大，为提供前端自动升级和安全调用机制。另外想用此播放插件还必须购买其DSS系统，而这套DSS系统的售价不菲，对非安防行业客户来讲性价比很低。

对于个别客户要求免插件的要求，主要仍是由于安全缘由。其实那些所谓免插件的实现方案中，也是须要浏览器从服务器下载JS版播放器的，而插件版下载的是本地程序播放器，只须要保证下载到本地的播放器程序是安全的便可，必要的话可开放源代码来打消客户对安全的顾虑。另外缘由就是须要额外下载插件程序致使部署和升级麻烦，为了超低延迟的播放效果，这个是必要的代价，何况前文提到的PluginOK中间件提供了播放插件的自动安装和升级机制，这样就大大下降了部署和升级的压力，效果比IE中的ActiveX控件更好。

4、总结

        一个好的技术实施方案，首先是要知足客户的需求，其次是尽可能下降开发、实施及运营的总成本，再次是是良好的兼容性和可靠性，最后需尽可能确保技术方案不能由于浏览器的升级而失效。本文基于当前最新的技术信息和实践经验，提供了这样一个稳定可靠、兼容性好、低延迟又可同时播放多路RTSP的低成本技术方案，以供你们参考。如还有疑问，欢迎加微信咨询：ZorroSoft