谷歌浏览器2020年12月将不再支持Flash（前不久…）flash插件已经逐步被替代，另外安装插件比较麻烦，用户体验其实不好，为了实现网页无插件播放ipc（网络摄像头）的视频该怎么办呢？我这里有两种方法：1，通过使用flv.js实现 2，通过使用webrtc实现 下面讲一下两种技术的利弊和实现的结果。网络上现在相关的资料不是很多，现在写一下分享一下经验（这里使用的是大华摄像头，大华一键报警，海康一键报警），文章最后有两种方案视频对比。
这里指哔哩哔哩（Bilibili）开源的flv.js，后端使用ffmpeg将摄像头的rtsp流进行转码，然后将http-flv的链接返回给前端，前端通过使用开源的flv.js播放这个http-flv链接即可实现网页播放。
flv,js目前使用的比较多，相关资料比较多，比较容易上手，但在搭建结束后发现延迟稍高（2s左右），实际这个延迟已经很不错了，但是和想要的效果还是有点差距，在控制球型摄像机转动时总是慢半拍的感觉（有点憨憨的感觉233）下面会有视频演示。
这个不是最致命的，关键是，使用ffmpeg在进行转码时，比较吃cpu和带宽，我笔记本是8代i5，在对一个摄像头进行转码时，cpu就高达70%，虽然后面对命令进行了优化，但是一直比较高，摄像头比较多的情况下可能比较难顶
另外，在我们实验室中，遇到下午网络使用比较多的情况下，拉出的流极易丢包（但其他时段网比较好的情况下，比较流畅，没有卡顿），在网页上的表现就是一卡一卡，然后转半天…，体验十分糟糕，虽然后面在ffmpeg转码加上了“-rtsp_transport tcp”，使得情况有些好转，但是还是非常的卡！一直在转圈圈。只能说非常不理想。这些迫使我们没法使用flv,js，必须尝试下其他技术。
如果一用户正在设备上查看摄像头视频，另一用户也请求了同一摄像头的视频，这时程序应进行判断，不需重复推流，直接将flv链接返回即可，避免对计算机资源的浪费，另外，用户关闭视频页面时，后端也要将其推流进程结束。
视频方面直接将rtsp流进行转码，那么音频呢（一键报警需要音频）？这个在当时也比较棘手，处理这个用了很长时间，使用的是pipe，但网上资料少之又少，在对ffmpeg进行转码时，两端为pipe，延迟较小，但相比与fmpeg操作文件和rtsp流的这种情况要麻烦一些，不够实现后声音延迟很小。报警器的声音发到网页时，通过rtsp流携带，但网页端的声音发回报警器时，需要使用ffmpeg对其进行转码（前端发的是webm格式的数据包，后端在拿到数据包后进行转码，然后通过sdk发给报警器即可实现）
webrtc和flv.js相比，资料少的可怜，如果使用这一方案，有需要去钻研学习，消耗的时间成本较高，但是效果比较出众，网页上播放非常完美。
使用webrtc，延迟极低，甚至比大华sdk中的demo还快。WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。 real-time即体现出他在延迟方面的表现。目前主流浏览器都支持，并且微信小程序中也可以使用webrtc。兼容性很不错。
使用webrtc，不需要对流进行转码，这点就很好的避免了以后请求过多服务器顶不住的情况。并且也支持网页在播放视频的同时播放音频（海康一键报警已测）体验很好。
如果，项目要求不高的情况下，使用flv.js也可以，上手比较容易。若是在延迟，资源等几个方面要求比较高的情况下，建议使用webrtc。测试时可以下vlc，恒星播放器等进行测试。想知道推出的流能不能再在flv.js中播放，可以使用 **http://bilibili.github.io/flv.js/demo/**这个链接进行测试。
关于flv.js我是使用了一个springboot项目，向前端透出接口
例如
可以看到我写的接口中包含的一些参数，通过这些参数进行拉流转码。
而webrtc我是需要首先调用add/ip地址/@dh(或者@hk)这个接口先将这个摄像头添加进去，然后调用play/ip地址来进行播放
大华sdk，webrtc，flv.js三者延迟对比
webrtc和北京时间对比
flv.js和北京时间对比
通过上面对比可以发现webrtc甚至比大华sdk速度还要快，并且支持音频（视频中没有展示），至此，项目中的音视频拉流播放算是结束了，前端将其封装进组件里也测试通过了。总的来说webrtc的效果很惊艳，想想现在央视新闻在连线记者时仍需要很长时间才有回应，我认为像这样优秀的技术在音视频方面应该更快的得到推广和使用。
希望文章对也在做相关项目的你有所帮助。
