视频中的图片的配置参数一般有亮度、饱和度、对比度、锐度等,以前一直以为这些需要通过厂家的私有协议SDK来设置才行,后面通过研究Onvif Device Manager 和 Onvif Device Test Tool 这两个onvif开发的必备工具以后,发现onvif协议也具备了修改 亮度、色彩度、饱和度这三个参数,当然这三个参数我见过的摄像机厂家(主流的十几种)都具备,还有些大厂做的设备还提供了其他详细图片参数的设置比如ICAT。
用onvif协议来对设备的网络信息进行获取和设置,这个操作在众多的NVR产品中,用的很少,绝大部分用户都还是习惯直接通过摄像机的web页面进去配置,其实修改网络配置的功能在大部分的NVR中都是具备的,网络的参数主要包括IP地址、子网掩码、网关地址、DNS解析地址、NTP地址、网卡信息、网络协议等,这些都可以通过不同的onvif命令来获取和设置,一直没有搞懂为啥这些要分开不同的命令去处理,其实大可以合并成一个命令嘛,搞得设置个网络信息还要post好多次的数据才行。
云台控制也是onvif功能中最常用的,最常用的功能排第一的是拿到视频流地址,排第二的就是云台控制了,云台控制的含义就是对带云台的摄像机进行上下左右的移动,一般云台摄像机都是带有一个小电机,一旦收到485或者网络来的正确的指令以后就触发单片机程序,然后单片机程序驱动电机进行转动,所以相对来说云台摄像机比普通的摄像机更耗电,当然价格也更贵。
以前不知道onvif也可以做抓拍功能,直到近期重新用Onvif Device Test Tool工具测试的时候,发现还有抓图的接口,于是抓跑分析出要收发的数据,然后加入到自己封装的onvif操作类中,这个抓图有个应用场景就是报警以后,直接通过onvif抓图,而不需要打开实时视频流,基本上不占用什么资源。
能够接收摄像机的报警事件,比如几乎所有的摄像机后面会增加报警输入输出接口,如果用户外接了报警输入,则当触发报警以后,对应的事件也会通过onvif传出去,这样就相当于兼容了所有onvif摄像机厂家的报警事件接收,在一些应用系统中,这个功能也是很常见的。接收摄像机的报警信息一般有两种处理方式,一种是订阅,订阅以后摄像机会在请求后一直阻塞等待,如果有新的报警信息则立即返回,否则需要到超时时间才会断开连接请求;还有一种是定时器主动轮询,不断的去询问是否有新的报警事件。关于订阅要阻塞等待的问题,这就涉及到另一个问题,一般Qt默认的并发请求最大6个(貌似这玩意好多浏览器也是这个规约,不知为何这么限定,为了节约系统资源?)这就意味着订阅机制下,最大只能有6个摄像机的报警事件订阅存在,超过就不行,除非有空闲的连接请求断开了,所以很多开发者会选择用其他的http post工具比如curl去处理。
抓拍是个很重要的功能,比如在报警视频联动中需要一张实时的图片,很多SDK不提供抓拍功能,而通过预览抓图,得到的图片已不具有实时性,那如何得到实时的图片呢?现在的IPC基本上都支持ONVIF协议,ONVIF协议除了提供RTSP的URL外,其实也给出了抓拍的URL,从Media的GetSnapshotUri获取。
严格意义上来说,Onvif处理这块算不上音视频开发的内容,为何重新整理放在音视频开发这个类别,主要是为了方便统一管理,而且在视频监控处理这块,通过onvif来拿到音视频流这是必经的阶段,也算是搭边的东西。上一篇文章写的是onvif设备搜索,搜到这些设备以后,第一件事情就是要对设备信息获取一下,比如获取视频流地址,配置套件信息、码流信息、分辨率大小等,这些信息的获取根据具体的需要去获取,也没有必要全部获取,毕竟很可能大部分的信息用不到,按需编码永远都是第一原则,第二原则才是考虑拓展性和稳定性,如果基本的需求都实现不了,那就不是一个真正的软件,考虑再多的拓展性和稳定性都是白搭,说的严重一点就是:所有编程语言都是垃圾,能解决实际需求并变现才是王道!
事件订阅是近期增加的功能,主要是因为遇到越来越多的一个应用场景,能够接收摄像机的报警事件,比如几乎所有的摄像机后面会增加报警输入输出接口,如果用户外接了报警输入,则当触发报警以后,对应的事件也会通过onvif传出去,这样就相当于兼容了所有onvif摄像机厂家的报警事件接收,在一些应用系统中,这个功能也是很常见的。
对设备设置时间很有必要,这个是必备的功能,毕竟大部分的前端设备比如摄像机本身不带BIOS电池的,所以没法存储时间,要么设置了NTP地址来同步时间,要么其他设备主动对他进行设置时间,如果时间不正确了,意味着本地画面显示的时间字符串,本地存储的视频录像文件等,都可能是不正确的,所以一般的处理是NVR一旦连上摄像机设备以后,立马将摄像机的时间设置成NVR的时间,这样就保持了一致。
最近业余时间主要研究音视频开发这块,前面的文章写了好多种视频监控内核,一旦将这些内核搞定以后,视频监控的相关功能水到渠成。做视频监控系统,绕不过onvif这玩意,这玩意主要就是为了统一一个大概的标准,能够对各个厂家的监控设备进行常用的一些操作,比如搜索、获取信息、云台控制、事件订阅、抓拍图片等,如果没有这个规范,那么各个厂家都各自为政,需要用私有的sdk去处理,这样就很麻烦很惨了,几十个厂家就需要几十个sdk,对于程序员来说简直是灾难,想想就很恐怖的事情,哪个程序员不想多活几年!
做视频监控系统,绕不过onvif这玩意,这玩意主要就是为了统一一个大概的标准,能够对各个厂家的监控设备进行常用的一些操作,比如搜索、获取信息、云台控制、事件订阅、抓拍图片等,如果没有这个规范,那么各个厂家都各自为政,需要用私有的sdk去处理,这样就很麻烦很惨了,几十个厂家就需要几十个sdk,对于程序员来说简直是灾难,想想就很恐怖的事情,哪个程序员不想多活几年!
上一篇文章写的是onvif设备搜索,搜到这些设备以后,第一件事情就是要对设备信息获取一下,比如获取视频流地址,配置套件信息、码流信息、分辨率大小等,这些信息的获取根据具体的需要去获取,也没有必要全部获取,毕竟很可能大部分的信息用不到,按需编码永远都是第一原则,第二原则才是考虑拓展性和稳定性,如果基本的需求都实现不了,那就不是一个真正的软件,考虑再多的拓展性和稳定性都是白搭,说的严重一点就是:所有编程语言都是垃圾,能解决实际需求并变现才是王道!
通过onvif来调整图片的Brightness(亮度)、ColorSaturation(色彩饱和度)、Contrast(饱和度)这三个参数,可以实时观测到监控画面对应的变化,比如讲亮度Brightness拉到最低,可以看到这个画面一片漆黑。通过onvif来调节图片的颜色光线,就无须通过厂家私有SDK去调节,当然厂家SDK能够去调节的参数肯定更多更全更好速度更快,这个功能用到的地方不多,大部分的时候其实还是安装调试期间,直接在前端摄像机的网页配置界面或者客户端界面上调整好,一般调整好以后基本上不会再去改动,尤其是经过验收的项目,经过专家的建议调整后固定在那个参数就行。
时隔一年多,重新对视频监控系统的onvif内核重写,一方面为了兼容Qt6,一方面按功能分类提高效率。整体逻辑思路是一样的,主要的改动是由于Qt6不再支持QtXmlPatterns模块(其实这个模块在Qt5的后面的版本也逐渐提示为废弃模块),onvif协议通信中的数据都是带有命名空间的xml数据,用QtXmlPatterns模块去解析是最合适的,现在全部改成了用最原始最基础的QtXml模块去解析,毕竟QtXml模块肯定是一直在的,这是相当基础的模块,无论以后Qt7还是Qt100肯定都会有。
预置位在视频监控系统中是不可或缺的存在,响应预置位功能的前提是要带预置位的云台球机,有些普通的云台球机其实不带预置位的,这个要检查清楚,硬件上不支持该功能的,你再怎么点也没反应。在这个视频监控系统的使用过程中,就有不少的用户会问这个问题,为啥他点了云台没法应之类的,前提是要硬件支持才行啊。
在视频监控系统中,对摄像机进行时间设置也是很有必要的,这样就和服务器或者软件这边统一了时间,一般在摄像机的画面上可以设置OSD标识当前时间,这样存储到视频文件中回放的时候,也能和本地的时间一致,一般的视频监控系统默认都会开启ONVIF校时,通过标准的公开的onvif协议来对前端摄像机设备进行时间设置,当然也可以获取时间。前端摄像机设备和后端管理软件或者服务器时间统一是非常重要的一个因素,本人经历过很多视频监控系统相关的项目,很多时候的报修情况就是因为前端设备时间和服务器端不一致的情况,导致的各种奇奇怪怪的问题。
整个onvif模块大部分的功能都有了以后,除了在demo上点点按钮可以执行获取结果显示外,最终还是要应用到视频监控中,在按钮上点点和系统中后台自动运行是两码事,比如onvif校时和事件订阅,不会说是傻到在监控系统界面上提供按钮给用户点击才去执行,最多做的应该是系统设置中提供两个开关比如自动校时、事件订阅,可以方便的开启这几个功能。开启以后等监控系统启动后自动去处理,比如挨个对摄像机进行校时处理以及订阅事件,为了能够做到添加摄像机后自动立即应用,特意改成了在打开摄像机视频画面的时候,主动去实例化DeviceOnvif类(每个摄像机都对应一个实例)
领取专属 10元无门槛券
手把手带您无忧上云