Performance Tuning with H.264

[jsylvia007]

So... Wow. ZM 1.32.x is significantly better on resources. I used to run it on a dedicated machine (Xeon-class CPU with 64GB DDR3 memory), and when doing the capture as "frames" (even with rtsp), the hard drive space required and the CPU load were always on the very high side. Now, I am also capturing at 1080p, 15fps. Since I've moved to this new version, the resource usage has dropped significantly, as has the required storage space...

I currently have 2 monitors for every camera. One is low-resolution, for motion detection, one is high-resolution and linked to the other one for the actual capture. Both capture at 15fps. After an hour, I delete the low-res versions, as they're only there to trigger the high-resolution event.

I did this, because the old way of capture didn't support the resources with a single monitor. There wasn't enough "change" percentage in the high-resolution to trigger an event.

Is this still the recommended method? Is there a better way?

An additional question about buffers... I have the buffers configured exactly the same with each the low-res and high-res monitors. Is this correct? Should one be more than the other?

[Pedulla]

Is this still the recommended method? Is there a better way?

Recommended???? Seems like there are so many applications of the ZM system hard to say. But that said, all the ZM systems I look after are still installed this way.

One of the developers, @Asker i think, has put together object detection rather than motion detection. Sounds cool and in the experimental stage. I might suggest reducing the frame rate on your detection/low res feeds to 2-4 fps. You're looking for changes to trigger recording. The slower the frame rate the easier to detect change.
If you can further just record the H.264 direct from the cam on the Hi-Res stream, then there's near zero overhead. I've seen issues with different cams interpreting the implementation of 264 differently, so you need to make sure you can view what you record on all the platforms you want to view from.

As far as buffers go, nothing has changed there, except that if you lower your frame rates as suggested you can lower your pre and post buffers accordingly. That'll save on /dev/shm space too.

[jsylvia007]

I might suggest reducing the frame rate on your detection/low res feeds to 2-4 fps. You're looking for changes to trigger recording. The slower the frame rate the easier to detect change.

Very interesting... I may look into this. I don't have any real issues, so I'm not sure I want to tinker with anything too much, but I will certainly keep it in mind.