⾕歌Chrome播放RTSP视频流完全解决⽅案！
⼀、历史背景
随着⽹络宽带的不断提升和智能⼿机的流⾏，RTSP实时视频流播放及处理不再局限于安防⾏业。在如道路、⼯⼚、楼宇、学校、港⼝、农场、景区等诸多场景实施的信息化系统中，绝⼤多数都采⽤的是B/S架构，隐藏迫切需要在浏览器中嵌⼊多路摄像头RTSP流低延迟(⼩于500毫秒)播放功能，⽽在IE及Chrome 45以下版本等浏览器中，采⽤ActiveX控件或NPAPI插件即可实现。然⽽美好总是短暂的，从2015年开始Chrome及Firefox等浏览器纷纷取消了NPAPI插件的⽀持，⽽IE⼜在与Chrome及Firefox等浏览器竞争的过程中不断被⽤户抛弃，到2020年其市场份额已降到可怜的个位数。微软在⼏经折腾后，索性也拥抱Chromium内核推出了新版Edge来杀死⾃⼰的IE和⽼版Edge，以挽救⾃⼰在浏览器领域岌岌可危的江湖地位。
在Chrome、Edge、Firefox等当前主流的浏览器中，即使是HTML5标准的Video也并未对RTSP流播放提供原⽣⽀持，从⽽导致如何在当前主流的浏览器中实现低延迟、低成本播放多路RTSP成为了⼀个重⼤技术难题。这⼏年国内外的技术专家经过不断研究总结，形成⼀些闭源或开源、收费或免费的⽅案，但多数时候⽆法完全满⾜客户的实际需求，要么兼容性和稳定性不好，要么播放延迟⾼，⾸屏画⾯显⽰慢；尤其是播放⾼分辨率的RTSP流时，卡顿、花屏现象难以根除。⽽且摄像头⽐较多时还需要专⽤服务器⾼负荷
的运转来⽀持转码转流，带宽的⾼频占⽤对系统其它业务的影响不可忽视，系统综合运⾏成本⾼，体验差。
⼆、现有⽅案
在浏览器中实现播放RTSP实时视频流，⼤体上有如下⼏个⽅案：
1.浏览器插件⽅案
此⽅案主要适⽤于在IE及Chrome 45以下版本的浏览器，在2015年前是绝对主流的选择。使⽤ActiveX播放控件或NPAPI播放插件实际调⽤的是本地原⽣程序进⾏直接播放，从⽽可充分利⽤本机硬件解码和硬件加速渲染播放，可实现低延迟、低成本多路稳定播放的良好效果。⼀般使⽤VLC这个最流⾏的开源跨平台多媒体播放器，IE及Chrome、Firefox低版本浏览器分别有对应的播放插件实现，VLC对移动端⽀持也⾮常好。此⽅案⾮常灵活，可以⽅便的对接各品牌的视频流，也可以很容易实现截图和录像功能。缺点是需要额外安装VLC客户端软件，对个别明确要求不能⽤插件的场景不适⽤。摄像头⼚家⼀般也会提供适配的播放插件，⽐如海康威视提供的播放控件Web版，是和⾃⼰的DSS 系统捆绑使⽤的，但不⽀持在Firefox⾼版本中运⾏。
2.先转码再转流⽅案
此⽅案需要架设⼀个或多个视频流转码服务器，先在服务器上对RTSP流⽤ffmpeg进⾏转码串流成RTMP，然后前端使⽤VideoJS再调⽤Adobe Flash Player进⾏播放，然⽽2021年开始基于Chromium内核的所有浏览器彻底取消了对Flash Player的⽀持，VideoJS因此失效。不过幸好还有开源的替代播放⽅案flv.js(github/bilibili/flv.js)⼯作原理是要求在服务端先把RTSP视频流转换为flv后⽤Web Socket或WebRTC推送到前端，前端收到后再转换为Video所⽀持的MP4后播放，这就导致RTSP视频流，需要经过2次转码才播放，画⾯延迟时间⼤幅增加，保守估计延迟⾄少是2-3秒级别了。况且如果有多路视频流时，服务器端转码和转流对CPU、内存、⽹络带宽的压⼒⼤幅度增加，长期使⽤综合成本很⾼，对⾼分辨率的视频流播放经常出现花屏、卡顿现象。此⽅案要求浏览器⽀持流媒体扩展特性(MSE)，且⽆法利⽤本机硬件加速实现解码和渲染播放。优点是可兼容移动端⽹页播放。
此⽅案在国内有TSINGSEE的免插件EasyPlayer RTSP播放器，项⽬地址是github/tsingsee/EasyPlayer和linkingvision的免插件播放器H5stream，项⽬地址是github/linkingvision/h5stream等，商业⽤途都是收费的。
3.先转流再转码⽅案
此⽅案的典型代表是Streamedian公司的免插件播放器Html5 RTSP Player，项⽬地址github/Streamedian/html5_rtsp_player。此⽅案需要架设⼀个Web Socket的视频流转发服务
webrtc浏览器器，前端连接到此服务器后，服务端不断把RTSP视频流通过Web Socket不断转发给前端的JS处理库，JS处理库再把视频流转换为Video所⽀持的MP4后播放。
此⽅案不⽀持IE浏览器，最⼤的问题是画⾯延迟达数秒，⾸屏内容显⽰慢，也⽆法利⽤本机硬件加速实现解码和渲染播放，CPU占⽤⾼，播放时花屏、卡顿现象，体验⽐较差。另外⽆法实现本地⾃动截图、录像等操作。此⽅案同样要求浏览器⽀持流媒体扩展特性(MSE)，对延迟不敏感的单源播放尚可，多路播放就只能洗洗睡了，另外根据⼀些⽤户的反馈，对各品牌摄像头的兼容性也不太友好，作为商业⽤途使⽤是不可⾏的。
4.扩展程序⽅案
此⽅案典型代表是基于Chrome浏览器的PPAPI插件技术实现的开源播放器VXG RTSP Player，项⽬地址是
github/VideoExpertsGroup/Chrome.RTSP.Player。此⽅案很显然不适⽤于IE和Firefox等浏览器，也不适⽤于低于45版的Chrome 浏览器。VXG RTSP Player是Chrome浏览器的扩展程序，对国内客户来说，由于⾕歌服务器在墙外，想要⼤规模⾃主可控部署是不现实的。另外最关键的是⾕歌已官⽅宣布，2021年6⽉终⽌对NaCl，PNaCl和PPAPI API的⽀持，因⽽此⽅案也⽆继续探讨的必要。
5.双内核⽅案
此⽅案典型实现是采⽤Chrome浏览器上的扩展程序IETab来实现，官⽅⽹站是www.ietab，通过在Chrome标签页界⾯覆盖加载显⽰⼀个IE内核渲染的⽹页，此⽹页再调⽤⽐如VLC的ActiveX控件实现。此⽅案和⽅案4⼀样，存在⼤规模⾃主可控部署难问题。另外和上⾯的浏览器插件⽅案类似，需要在播放终端电脑中下载运⾏程序，对⼀些⾼安全要求⽆插件播放的场景来说不适⽤。最⼤的问题是在Chrome⽹页中对播放控件的控制很难实现，只有⽹页和播放控件都是在IE内核环境下才可以，⽽IE对当前⼀些新技术和前端主流框架的兼容已经不⾏了，况且IE对运⾏和下载安装ActiveX控件经常弹出警告，⽤户体验很差，维护升级也很⿇烦。
6.Wasm⽅案
此⽅案采⽤的是Chrome等⾼版本浏览器所⽀持的⼀种⽅便把更复杂的原⽣应⽤直接搬进 Web 的标准技术，然⽽对浏览器的兼容存在很⼤问题，IE肯定是不⽀持的，低版本的Chrome及Firefox等浏览器也不⽀持Wasm，具体兼容性可看这⾥caniuse/wasm。实现的基本思路就是把RTSP视频流通过ffmpeg的Wasm版软解码成Video所⽀持的MP4后播放，由于Wasm不⽀持硬件解码，对多路同时播放来说，终端电脑的CPU和内存占⽤会⽐较⾼，性能也堪忧。此⽅案有时应⽤在需要⽀持H265编码的场景，同样要求浏览器⽀持流媒体扩展特性(MSE)。由于存在诸多兼容性问题，此⽅案实际应⽤的案例较少。
三、改进⽅案
通过上述总结的现有技术⽅案可以看出，想要在浏览器中实现低延迟、低成本的多路RTSP同时稳定播放，只有不转码并充分利⽤终端电脑的硬件加速特性这两条才⾏，这样就只能采⽤类插件的外接⽅案。核⼼就在于如何在各浏览器中实现⼀个统⼀的不依赖浏览器⾃⾝扩展技术的外接系统，同时必须对各品牌及各版本的浏览器有⽐较好的兼容能⼒才具有较⼤的实⽤价值。所以改进⽅案思路就是要在浏览器⽹页中的指定位置和⼤⼩，实现⼀个内嵌到⽹页中显⽰的播放窗⼝，前端还必须可对这个内嵌播放窗⼝进⾏控制，⽽且播放窗⼝必须跟随浏览器窗⼝的移动和缩放、⽹页滚动、标签页切换、关闭等操作进⾏⾃动联动。这就要求播放窗⼝必须是本地原⽣程序实现，最好⽤⾼性能的C++语⾔来开发，还可充分利⽤终端电脑的硬件加速特性。这个播放窗⼝同时提供Web Socket的服务端和JSON打包命令的解析执⾏模块，前端就可以通过Web Socket连接后发送JSON打包的控制命令实现控制播放窗⼝。
⽬前市场上已经有采⽤此思路实现的相关软件和实施案例，⽐如（www.yuanmaster/），提供了⼀个统⼀的不依赖浏览器本⾝扩展技术的外接系统，能实现当前主流浏览器的全兼容，包括低版本的Chrome和IE浏览器；⽽且⼩程序的下载和安装提供了类似ActiveX控件的机制，去掉了⼀些影响⽤户体验的告警并附加了调⽤⽅安全验证机制。⽽这个播放窗⼝程序也提供了⽐较好的范例实现，难能可贵的是在这个播放窗⼝还直接实现了多路RTSP的同时播放⽀持，可点选切换播放窗⼝焦点和全屏播放。据了解，此⽅案已经成功在机场、地铁站、交管局等客户现场完成实施并取得了良好的效果，获得了客户的⼀致好评，毕竟能实现低延迟、低成本的多路同时播放是硬道理。
某视频监控⼤⼚最近也发布了类似的版本，不过经过测试发现，不⽀持Firefox⾼版本浏览器不说，其播放窗⼝程序框架采⽤臃肿的QT来实现的，看上去播放窗⼝只是模拟显⽰的效果⽽不是真正内嵌到浏览器中的，导致和浏览器的联动效果⽐较差，程序包也很⼤，且未提供前端⾃动升级和安全调⽤机制。另外想⽤此播放组件还必须购买其DSS系统，⽽这套DSS系统的售价不菲，对客户来说性价⽐很低。
对于个别客户提出的免插件播放要求，主要是担⼼安全问题。其实所谓的免插件实现⽅案中，也是需要浏览器从服务器端下载JS版播放器的，⽽外接版只不过下载的是本地版播放器，只需要保证下载到本地的播放器程序是安全的即可，必要的话可通过开放播放器源代码来打消客户对安全的顾虑。还有原因就是需要额外下载外接程序导致部署和升级⿇烦，但为了超低延迟的稳定播放效果，这个就是必要的代价了，况且前⽂提到的猿⼤师中间件提供了播放⼩程序的⾃动安装和升级机制，这样就⼤⼤降低了部署和升级的压⼒，效果⽐IE中的ActiveX控件还好。
：
：
四、总结
⼀个好的技术实施⽅案，⾸先是要满⾜客户的刚性需求，其次是尽量降低采购、开发、实施及维护的总
成本，再次是是良好的兼容性和稳定性，最后需尽量确保技术⽅案不能因为浏览器的升级⽽失效。本⽂基于当前最新的技术信息和实践经验，提供了这样⼀个稳定可靠、兼容性好、低延迟⼜可同时稳定播放多路RTSP的低成本半开源技术⽅案，尤其适合播放⾼分辨率的RTSP，以供⼤家选型参考。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。