Zoneminder, Onvif CPU and RTSP capture

[MindrustUK]

Hi all,

I used to use ZoneMinder a while ago but moved to a dedicated Dahua DVR which has worked just fine. Now I’m looking to upgrade my cameras from analogue to IP digital devices so playing with ZoneMinder again.

I’ve got a few Hikvision cameras to start and am experimenting with other devices as I get my hands on them. My initial experiments have shown that ZoneMinder seems to work just fine, however due to motion detection and recoding drives the CPU load through the roof on a smaller box. I’ve also been looking at Synology surveillance station as another possible alterative but I’d rather stay open source.

Looking at some of the threads below there appears to be two issues which may be impacting things here:

https://www.bountysource.com/issues/935809-store-events-in-a-video-format https://github.com/ZoneMinder/ZoneMinder/issues/146 https://www.bountysource.com/issues/935776-onvif-support https://www.bountysource.com/issues/999780-feature-request-add-onvif-support

To this end I have some loose ideas that hopefully will help, I’m sure these have been discussed before but I felt they may be worth a mention to maybe get some input.

The first is storing events as images rather than video. As the video is RTSP maybe this could be read in its native format into a circular buffer in memory then on a motion event dump the preceding five seconds (for example) before the event out of the buffer then continue dumping the RTSP stream in real time followed by say another five seconds of video after the event unless another event is received in which case recording time is extend by another n seconds. Effectively just dumping the stream straight to a hard drive and tidying it up into a readable format later. Admittedly this isn’t good as far as disk size goes but that might be an option to offer to the end user to tweak? Having this raw video is probably also beneficial for passing to other processes for post processing such as recognition of faces or license plates.

The second is motion detection, I was thinking as ONVIF 2.x Profile S implements motion detection on camera, this could lower CPU impact by offloading any motion detection to compliant devices.

I’ve been experimenting with some of the information in the afore mentioned posts (and ponvif found here: https://raw.githubusercontent.com/ltoscano/ponvif/master/lib/class.ponvif.php) and have come up with the below (Yes I know passwords are exposed but these are the default for Hikvision devices anyway):

curl http://192.168.0.2/onvif/Events -d '<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"><s:Header><Security s:mustUnderstand="1" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><UsernameToken><Username>admin</Username><Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">96V8G+ax+2SRLd67aWkEAdLKdQQ=</Password><Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">ICdmdhk=</Nonce><Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">1999-11-30T00:00:05.000Z</Created></UsernameToken></Security></s:Header><s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsnt:Subscribe><wsnt:ConsumerReference><wsa:Address>http://192.168.0.3:8000/consumerinterface?from=192.168.0.2%26serno=000000000000</wsa:Address></wsnt:ConsumerReference><wsnt:InitialTerminationTime>PT9M</wsnt:InitialTerminationTime></wsnt:Subscribe></s:Body></s:Envelope>'

This curl example creates a subscriber on the camera which on motion causes an soap call which reads something like this:

~$ nc -l 8000
POST /consumerinterface?from=192.168.0.2%26serno=000000000000 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml; charset=utf-8
Host: 192.168.0.3
Content-Length: 2694
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:tst="http://www.onvif.org/ver10/storage/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" xmlns:dn="http://www.onvif.org/ver10/network/wsdl" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:tmd="http://www.onvif.org/ver10/deviceIO/wsdl" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl" xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12" xmlns:http="http://schemas.xmlsoap.org/wsdl/http" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsadis="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:wsrf-bf="http://docs.oasis-open.org/wsrf/bf-2" xmlns:wsntw="http://docs.oasis-open.org/wsn/bw-2" xmlns:wsrf-rw="http://docs.oasis-open.org/wsrf/rw-2" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsrf-r="http://docs.oasis-open.org/wsrf/r-2" xmlns:trc="http://www.onvif.org/ver10/recording/wsdl" xmlns:tse="http://www.onvif.org/ver10/search/wsdl" xmlns:trp="http://www.onvif.org/ver10/replay/wsdl" xmlns:tnshik="http://www.hikvision.com/2011/event/topics"><env:Header><wsa:To env:mustUnderstand="true">http://192.168.0.3:8000/consumerinterface?from=192.168.0.2%26serno=00000000000</wsa:To>
<wsa:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify</wsa:Action>
</env:Header>
<env:Body><wsnt:Notify><wsnt:NotificationMessage><wsnt:Topic Dialect="http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet">tns1:RuleEngine/CellMotionDetector/Motion</wsnt:Topic>
<wsnt:Message><tt:Message UtcTime="2014-04-16T19:23:33Z" PropertyOperation="Changed"><tt:Source><tt:SimpleItem Name="VideoSourceConfigurationToken" Value="VideoSourceToken"/>
<tt:SimpleItem Name="VideoAnalyticsConfigurationToken" Value="VideoAnalyticsToken"/>
<tt:SimpleItem Name="Rule" Value="MyMotionDetectorRule"/>
</tt:Source>
<tt:Data><tt:SimpleItem Name="IsMotion" Value="true"/>
</tt:Data>
</tt:Message>
</wsnt:Message>
</wsnt:NotificationMessage>
</wsnt:Notify>
</env:Body>
</env:Envelope>

My thinking is not to try and implement all ONVIF features in one hit, but simply to bodge together some sort of low CPU usage using some of these tricks then build it up to achieve full ONVIF compliance such as device discovery and capabilities description. Unfortunately my understanding of SOAP and WSDL isn’t really there yet but as per the above threads there appear to be a few of these which may be ported. I’ve been testing a few things in Python but I can’t really offer any C code for a merge as my C isn’t really up to scratch. It seems that WSDL would be used to generate the stubs and then these would be posted using SOAP my above curl example just appears to be shortcutting this with a static version.

Any thoughts?

TL;DR: Could we just write the native camera stream to disk and use on camera intelligence to decide when there’s motion to reduce CPU overhead?

[knight-of-ni]

I think most of us would love a product that does edge based motion detection and records the native stream to disk w/o transcoding into another format. However, recording the native stream straight to disk greatly increases the complexity of client playback and may not even be possible using just a web browser.

This is currently outside the scope of what the few developers of this great open-source project are willing to do for free. Not because we don't want to, but because we are essentially just volunteers, each with our own day jobs.

If you would like something like this to be added, you can either step up and do the work yourself or place a bounty to pay someone else to do the work for you.

In either case, I recommend you read up on some of the existing issues already created that touch on this topic.

Note that we are testing a branch of zoneminder that records video into an mp4 container, rather than jpeg's. It doesn't reduce reduce cpu overhead, but it is a necessary first step towards modernizing zoneminder.

[m-bene]

Some mor data points on this: I've done some experimemnting with zoneminder monitors in nodect mode using motion detection triggers provided by cameras; I've used both email notification and http notification from the camera to trigger alarms. So far, after using cameras made by axis, d-link, trivision and foscam I've come to the conclusion that the motion detection provided by the cameras is way, way inferior to what's available in zoneminder. I'd be interested if you've got better experiences with on-camera motion detection.

[knight-of-ni]

Most modern, commercial software uses motion detection on the edge these days (a.k.a. the camera does the motion detection) so I can certainly understand why we get questions asking why zoneminder doesn't implement this. With good cameras, it works well enough and allows one to get well over a hundred ip cameras at high frame rate & resolution on a standard 1U server w/o breaking a sweat. The server does virtually no processing because all it is doing is writing the native stream to disk.

As one might expect, the quality of motion detection is directly proportional to the cost of the camera. Cheaper cameras aren't going to have the hardware resources to do decent motion detection. Since zoneminder's main demographic is the home or small business owner with a small budget, we wouldn't be benefiting the majority of users by spending a lot of time on edge based motion detection. Most simply would not be willing to buy cameras that cost $800 or more, and they would be severely disappointed if they tried this using cheaper cameras.

From my day job experience, nearly all the cameras found on popular sites like Amazon can be considered cheap(er) cameras targeted for the home user. Axis is the exception, but you can see that in their higher cost. That does not mean cheaper cameras are no good. However, one can expect the manufacturer to compromise features (e.g. motion detection) to keep the cost down.

[connortechnology]

Would be nice to build alternate firmware for cameras using zm's detection. Wish I had the skills/time.

[knight-of-ni]

I am consolidating the number of open ONVIF-related threads. Please see #478 for continuation of the ONVIF discussion.