PVR-like post Processing for IPCams

Anything you want added or changed in future versions of ZoneMinder? Post here and there's a chance it will get in! Search to make sure it hasn't already been requested.
Post Reply
rmitchell
Posts: 1
Joined: Fri Jan 13, 2017 2:30 am

PVR-like post Processing for IPCams

Post by rmitchell »

Hi
I'd like to request make a request.

First I should explain some background. I've been using "Motion" for years. I'm a cheap SOB, so back when megapixel cameras were $10,000, I just used megapixel USB cameras with an old used computer. Now that megapixel IP cameras don't cost as much as a car, i decided to buy some and give ZM a try. I'm impressed with the ZM interface. However one issue that has always nagged me is the amount of CPU used for these software packages such as Motion or ZM. I was excited when I saw that ZM is capable of using a low resolution stream from the IP camera to do the motion detection while triggering the high resolution stream to be saved. So I added the IP camera to ZM (3MP@25fps) and just the one IP cam is using over 50% of the dual core CPU. To my disappointment, it appears that the software is processing every frame of the high resolution stream, even though there is no motion detection.

BTW - please do not suggest lowing the resolution or frame rate. I hate, hate, hate, grainy or choppy video as a solution for a problem that should not exit.

What I would like to propose is that there be no "live" processing of the high resolution stream, but rather it is simply written to disk (ala PVR) and events can be later extracted by post-processing.

As a proof of concept, i just wrote some simple perl/shell scripts that take the high resolution stream and writes it to disk in a series of files that are a few minutes long each. A separate detection process watches for events. In this case I used Motion to watch the low resolution stream, however this can be any process such as watching the http stream from the camera's own motion detection, or something from a PIR sensor, etc. Anyway, the detection process, just detects an event and writes the event time to the database. The post process just periodically checks the database for an event and it then (post) grabs the high resolution files and assembles them for the event video. Of course, computers are fast enough that this "post" process happens right away, but the point is that it does NOT need to be in real time so as to kill the CPU.

Here is the net result:
  • The PVR process that is saving the high resolution stream takes almost no CPU/memory
  • The detection process to detect an event takes almost no CPU/memory
  • The post process to assemble the video takes almost no CPU/memory
There is an added bonus. I absolutely need pre-capture frames. I don't know if this is the case with ZM, but with Motion, having pre-capture frames is a memory killer. With the PVR method, the frames are on disk and no need to store them in memory, So if I'm storing (say) 2 minute video files, the post process just selects the first video that has at least (let's say) 30 seconds of pre-event video. This gives me a "large" amount of pre-capture which i never could have done with Motion (with Motion you are talking about a few frames of pre-capture only).

BTW, above I mentioned that in the proof of concept i'm using Motion to detect events. If I watch the low resolution stream, it takes very little CPU. However i see the camera has it's own motion detection and you can just watch the http stream, hence use no CPU at all. The beauty of the post-process method is that you can replace the trigger method with anything that just writes an event to the database. Also, if you have a lot of false detects (bugs, cobwebs, birds, rain, etc) you can use a PIR or something more reliable with no monumental software changes (just write an event to the database and let the post process take care of it).
Post Reply