PVR-like post Processing for IPCams
Posted: Fri Jan 13, 2017 3:40 am
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:
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).
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
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).