工业摄像头推流对接Web客户端

佩奇快跑
119 阅读10分钟

工业摄像头推流对接Web客户端

摄像头的两大类型

市面上的摄像头主要分为两种 USB 与 网络传输(有线与无线)，这两种摄像头本身所面向的群体受众以及需求也存在较大的差异，第一种也就是传统意义上最常见的比如最常见手机摄像头，视觉识别的机器人，网络视频博主直播，都采用的是这种 USB 摄像头，而对于一些安防报警检测，交通检测，工业行业实时监测。

但其 USB 摄像头与 网络摄像头本身在其工作原理上有着较大的差别，由于 USB 摄像头都是一般与 PC 主机进行串口连接，其连接闭环线路在大多数情况下都是特别短的，所以说这期间对于数据传输效率本身来说是比较高的，所以市面上的绝大多数 USB 摄像头都是将采集到的视频流数据，通过 USB 的协议直接发送给 PC 端的，常见的目前 USB 接口都是 3.0 接口也就是最大允许的带宽是 5Gbps，稍微高端一点的摄像头会采用一些压缩算法如 MJPEG 压缩来减少带宽的占用。

对于网络摄像头来说，本身网络传输占用的也是带宽，但这个带宽的资源是比较宝贵的(基本是千兆网最理想最快的速度为 1Gbps，这对于未采用高效算法压缩的视频而言远远不够)，这里的带宽其实就是指所谓的流量。所以网络摄像头都会采用更加高效的压缩算法用于保证在不损失原有画质的基础之上，将传输的视频流数据占用空间降到最低，因此也就是有了 H.264、H.265 这种高效的视频编码。

需要注意的一点是由于 USB 与 网络摄像头 本身所受传输硬件的制约，其本身两种不同类型的摄像头在压缩编码的处理端也有所不同，USB 摄像头本身不需要进行压缩，只需要将是视频流数据保存到 PC 端，PC 端将数据进行编码压缩，由于未压缩的视频本身所占用的空间比较大的，而且压缩后的视频更加便于网络的流式传输，因此压力在 PC 端，而网络摄像头本身是通过内部的硬件对视频本身进行压缩，从而在减轻了 PC 端的负担的同时也提高了网络的传输效率。

image.png

个人 PC 自带摄像头直播的背后简单基础原理

  • USB 个人 PC 摄像头 image.png

  • 网络摄像头 image.png

从图中可以看到 USB 摄像头没有进行任何的网络连接，只是通过串口将视频流的数据采集到了个人的 PC 计算机，其他人是无法通过局域网去访问到采集到的流数据的，相当于这份流数据一直在一个不对外公开的黑盒里。如果要让这份流数据被别人访问到，无论是局域网还是外网，都是首先需要想办法将这份数据给暴露出去，那唯一的选择就是通过网络将这份实时流数据给发布到局域网或公网当中。

文件传输有OSS对象服务器，访问网页有 WEB 服务，操作数据库有 DB 服务，同样的为了更方便高效的处理流式数据(音视频的实时数据)，也有其流服务器。访问其主要是客户端完成推流、用户端进行拉流。

关于摄像头的推流、拉流、以及流服务器

  • 推流

    • 推流其实无论是对于 USB 摄像头还是 网络摄像头 ，本质就是将流数据推送到流服务器端。但取决与本地的硬件设备其推流的方式以及对应的流服务器也有些许不同。目前的流服务器主要有三大类 RTMP 、RTSP 、HLS 。目前笔者本人接触使用过的也就前面 RTMP 与 RTSP 这两种，RTMP 流服务器是最好搭建的由于 Nginx 本身是有 RTMP 模块的，只需要安装该模块后,在 Nginx 配置文件当中开启 RTMP 模块后启动 Nginx 即可。但其最主要的问题是在于对于原生的 RTMP 流现在的浏览器内核升级之后全部都已不支持了，因此嵌入到网页当中是无法播放的，除非使用一些插件，比如海康本身自己的视频就是 RTMP 的流格式，海康自己的dll本地插件就可以支持在 WEB 页面播放，或者在浏览器当中安装 Flash 播放器，但自从自从2020年之后就已经不支持(据说是因为Adobe公司对 Flash 摆烂了，存在很多的安全漏洞隐患)。而对于 RTSP 这种格式本身是用户网络摄像头的推流的，因此现在浏览器同样也都不支持该流格式。HLS 这种格式是将视频变成了视频帧，有相当大的延迟，笔者当初也没有做过该方面的测试。

  • 拉流

    • 将数据推送到服务器之后，便是客户端将流数据拉取到本地，这里有WEB端和桌面端。桌面端对于上述的 RTMP 以及 RTSP 这种流格式都有很好的处理方式，但对于 WEB 端却是比较麻烦的,由于 WEB 端目前主流的浏览器都不支持原生 RTMP 以及 RTSP 这种格式的流数据，因此都是需要将拉取到的流进行一次转码，转成浏览器支持的 FLV 格式，这样就可以之间支持 FLV 的 js 库调用在 WEB 端接收流数据以视频的形式展示了。

  • 流服务器

    • 前面笔者说到的无论是 RTMP 、还是 RTSP 以及 HLS 这些流服务器本身来说都是属于最原始的原生流服务器。其实在企业当中开发大多数都是使用的在这些流服务器基础之上二次开发包装的更加高级的流服务器。这些流服务器功能更加丰富高级，提供了强大的并发、丰富API接口。之前我有一个关于将网络摄像头与 USB 摄像头进行对接的业务，网络摄像头当初主要适用于工业大屏的AI智能预警监测，而 USB摄像头是为园区学生进行远程开发板监控而准备的。当时为了节省时间本地后端服务使用 Java 交互调用 FFmpeg 将流数据推送给 ZLMediaKit 服务器，本地 WEB 页面通过拉取 ZLMediaKit 转换后的 FLV 流数据配合哔哩哔哩的开源框架 Flv.js 进行播放控制。

关于视频编码 H264/H265

其实关于 H264 与 H265 本身就是一种音视频的压缩技术，USB 摄像头我遇到的并不多，但是对于网络摄像头这个是硬件自身就携带的，也是必须要有的，否则如果视频以原格式 MJPEG 或其他传输那必定是会将带宽全部占用完的，数据量将会非常的大，海康威视的摄像头的管理页面本身也提供的了 .H264 与 .H265 两种编码规范，当然 265 是 264 算法的升级版必定器压缩质量要更高一些。

image.png

参考资料

开发场景

关于摄像头工业大屏的应用

之前我们需要给鄂尔多斯场去做一个用于实时检测的数字孪生系统，购进的摄像头有 HD 的高清摄像头与 AI 摄像头，AI 摄像头内置了海康自己的 AI 模块，只需要将我们自己训练的识别模型放到该模块当中就行，HD 高清摄像头主要用于将抓拍的图片进行本地的算法分析，上报最终数据。网络摄像头其实只需要通过推流工具通过 RTSP 的将流数据推送给服务器就行，由于海康威视摄像头默认是  .H264 /  .H265 编码，所以再推流的时候无需再进行压缩转码，原生的流数据本身就是很可靠的。海康威视本身自带了 WEB 页面播放视频的插件与 Demo 只需将自带的整合到 Vue 当中进行登录注册就行。

image.png 后续采购了一些 USB 摄像头，用于煤炭巡检小车的安装，由于小车是通过 wifi 模块，4G 模块上的开发板连接的，无法连接到小型工控网络摄像头上的，后面采用 USB 摄像头与开发主板对接，开发主板将采集到的 USB 视频流数据，通过开发版上的 ffmpge 进行转 .H264 编码 之后进行流推送到流服务器，WEB 大屏再将推送的流数据拉取到客户端。

image.png

实际落地遇到的瓶颈问题

USB 视频推流出现累计延时和长时间连接掉线

当时为了缩小体积，采购了低成本摄像头。在实际的本地开发环境下测试的时候发现视频会随着时间的推移延时会不断的累加，经常出现连接掉线，只要一旦连接到工控巡检车视频页面之后，流量就会飙升，带宽几乎被占用完，后面发现购进的摄像头本身是不自带 H.264 硬编码的，在使用 ffmpage 推流的基础之上进行一次视频压缩转码，转为 H.264 编码推送。在后续的线上生成环境下，为了减少对于资源本就不多的开发版性能的占用，就统一采购了 H.264 编码规格的摄像头。

输入输出设备增加导致的视频页面卡顿延时问题

由于摄像头连接的流服务器是要提供给多个部门去使用的，在刚开始使用的时候处于测试阶段接入的用户量并不多，注册的检测用户也不多，后续随着接入的硬件与用户数量增加，会出现流服务器页面卡顿的问题。由于使用的 ZLMediaKit 流服务器性能本身是很好的，查看服务端的硬件资源占用率发现带宽经常跑满，者其主要是因为单机部署，由于在拉流的时候接入的用户太多，导致带宽不够，通过扩展了一个额外的 ZLMediaKit 流服务器构建了集群 。

如何保证推流的稳定以及中断重连机制

关于这点其实主要是两方面：

  1. 网络中断，比如说摄像头推流怎么能保证在网络突然中断，又突然连接这种情况下保证继续推流呢？主要是分为推流端中断和流服务器中断以及拉流端中断。推流端中断（摄像头掉线、进程崩溃、网络故障），拉流端中断（播放器断开、解码失败）
  • 推流端

image.png

  • 拉流端比较简单，只要是播放器断开，流服务器在长时间未检测到拉流数据就会自动的关闭该流输出。若是拉流失败设置自动重连机制超过5次之后，默认将异常信息提醒到客户端。
avatar
文章
阅读
粉丝