ZoneMinder Forums

I'm currently still using ZM 1.30.4. But I gave another PVR a try, and the one thing I really liked was "native" h264 recording: I could do the equivalent of ZM's always-record with negligible CPU utilization (my cameras output h264 streams).

If I understand correctly, ZM added experimental h264 pass-through in 1.31. And with the 1.32.0 release, I assume this is considered a production-ready feature?

I got to thinking about my ideal camera setup. I believe it's similar to ZM's mocord (record-everything plus motion detection), but with the following spin: instead of motion detection happening in real-time, it does it only when requested (on previously recorded footage). This could also be done as batch processes, on some schedule (say every four hours). This would obviously give up real-time alerting. But I'm not currently using that feature. My camera use-case is more about "postmortem" analysis, i.e. if something did happen, I'd go back and review camera footage. But 99.999% of the time, I have no need to review footage.

In other words, with the CPU and storage-space efficiency of h264, I want to record everything all the time. But if I ever need to go back and look at footage, I want an easy way to navigate the footage. Let's say I have a dispute about package delivery. Ideally, I'd go into the ZM console and say, "Do motion detection analysis on the last 24-hours of recorded footage per my modect rules, and generate events from those for my review."

Is something like this possible?

For what it's worth, I currently have three cameras. For each camera, I have a high-resolution stream doing modect, and a secondary low-resolution stream for constant recording. The latter is a backup against important stuff getting missed by modect. I also have a batch process to convert all events (i.e. high-res modect and low-res record) to an h264 stream for space-efficient archiving. But all this adds up to a lot of CPU and I/O overhead. For my use case, it seems far more efficient to just always record a single hires h264 stream natively, and to motion-detection analysis as-needed (which is very rare).

Thanks!

Maybe not exactly what you're asking for but this gives you a way of constantly recording High-res H264 24/7 without crippling your system (running zmc on a bunch of 4MP cameras needs a load of horsepower).

I use MODECT on the low-res streams from the cameras to provide motion events and I can go look at the high-res H264 if needed.

Note: there will be a new version of the script coming along shortly. I screwed up setting the correct StorageId in the Event and zmaudit is getting a bit enthusiastic about cleaning out the CONTINUOUS recordings as there's no Frame records for the events.

To fix the fix the first issue simply set line 67 to read
I'm not quite sure what to do about the second issue. For now I've set AUDIT_MIN_AGE to a week while I think about it.

May I suggest you do as I do, I dump the high quality stream to disk 24/7 and modect on the smaller stream, this means i have a less cpu intensive stream being analysed for alarms, and if I need better detail (to read a car lisence plate for example) all I do is match the time stamp and look it up in the good quality recordings. for completeness you could mo-cord on the smaller streams 24/7 aswell to another disk, that way you have 1 disk that has say a weeks worth of good quality and another disk with a month or more of poorer quality. Thanks to storageareas and passthro this is fairly light on the cpu and easy enough to set up.

evolotion wrote: ↑Mon Sep 24, 2018 11:59 am May I suggest you do as I do, I dump the high quality stream to disk 24/7 and modect on the smaller stream

That's exactly what I'm doing and what I suggested above.

evolotion wrote: ↑Mon Sep 24, 2018 11:59 am Thanks to storageareas and passthro this is fairly light on the cpu and easy enough to set up.

Ummm.... almost. Zoneminder *always* decodes the stream into frames. Even if you are just monitoring and use H264 passthrough it's still doing the zmc frame decode which becomes a heavy CPU load with a bunch of <high>MP cameras... hence the script I wrote and referred to above. The high-res stream bypasses Zoneminder apart from creating 'event' entries in the database to make replay easier for non-techie users.

Yes I replied to the OP as it were and read your post after, I didnt see the point deleting my post, no offence meant. Fwiw the cpu usage dumping the high resolution streams on my particular setup was/is acceptable and a million times better than running the same cameras before the passthrough feature came about. All that said I am going to give your script a whirl, never hurts to save some cpu usage

Thank you both for the idea(s). I think I might give that a try. Current CPU usage isn't really a problem, other than I know it's sub-optimal. Batch processing would IMO be the best, though, because it would in theory allow the CPU to enter a low-power/idle state for longish periods of time.

I haven't looked at the ZM code, but it seems like all the smarts for doing what I want is there... now that I think about it, I could probably hack something like this together. I start with h264 pass-through recording of everything. Then on some kind of schedule (e.g. via cron), I use the recordings to playback a "virtual" camera. Ffmpeg can do this, see ZoneMinder Virtual Camera. Then I create a ZM monitor with motion detection that starts and stops on the same schedule as my virtual camera.

I suppose the problem with that, is that the ZM event timestamps would be messed up, i.e. ZM wouldn't know the virtual camera was not real time. But my cameras actually overlay a timestamp, so I could use that to cross-reference where to look in the always-recorded stream. And maybe I could fix that with some SQL hacking anyway.

I have everything working now, which gives me a little hesitation to go messing with it. First step is to upgrade, since I'm still on 1.30.4. There's always the risk vs reward analysis of possibly breaking something in the process of enhancing it, when it's already working just fine (albeit sub-optimally).

Thanks again!