Hallo,
i have a 4k/20fps/h265 stream that has I-frames every 50 frames. I cannot change this (its h/w restricted). Zoneminder demands an ImageBufferCount 101 for this streams. But why? Wouldn't 51 be enough? The problem is it would be 3840×2160×3×101=2513MB and i'm short on RAM.
Is there anything i can do in ZM to get the buffer down to 51?
Why ImageBufferCount 101 for 50/I-Frames?
Re: Why ImageBufferCount 101 for 50/I-Frames?
This issue is that motion analysis happens after capture. We need to keep everything since the last keyframe. Technically zma could be so far behind capture that it could be analysing at the tail of the queue and capture is at the head. Capture doesn't know where analysis is happening. Since the buffer size is fixed there needs to be room for analysis to be behind while still storing a whole GOP in front and behind the analysis thread.
1.35 does this a little better. We no longer use a fixed buffer. As long as the analysis thread keeps up, it will free up as many GOP's as it can, AND free the raw images used in motion detection/live view. However, if it gets stuck (writing to db or finishing an event or something weird) it might STILL use up 2*keyframe interval + 1 packets in the queue.
You can just live with the warning message.
1.35 does this a little better. We no longer use a fixed buffer. As long as the analysis thread keeps up, it will free up as many GOP's as it can, AND free the raw images used in motion detection/live view. However, if it gets stuck (writing to db or finishing an event or something weird) it might STILL use up 2*keyframe interval + 1 packets in the queue.
You can just live with the warning message.
Re: Why ImageBufferCount 101 for 50/I-Frames?
Bluemax, you're post got me thinking, and if you're short on memory and using h265 see the post I made after having read yours...
viewtopic.php?f=40&t=30673
Assuming you have sufficient storage, which you probably do if you're using h265, you probably don't need more memory. h265 is crazy efficient at making the video size small, and hard drives are cheap. Memory isn't.
viewtopic.php?f=40&t=30673
Assuming you have sufficient storage, which you probably do if you're using h265, you probably don't need more memory. h265 is crazy efficient at making the video size small, and hard drives are cheap. Memory isn't.
Re: Why ImageBufferCount 101 for 50/I-Frames?
Thanks, its 720p for ZM then for now and the camera will do the 4k recording. Motion detection quality is not coming close to ZM though. Everything has a price. I'm currently recording 720p/h264/20fps/modect in a 1.5GB tmpfs folder. Keeps events for ~24-48h.
Edit: I've setup a dual stream setup (analysis on 720p/h264, record 2160p/h265). 720p is 'modect' without any writers and h265 is 'nodect' and linked to the other stream. It seems to work even though empty events appear on the 1st stream as well. The nodect stream still needs 10 (useless?) buffers.
But the biggest problem is the jpg event player. I can't get satisfiable results with Firefox. Too laggy and low fps no matter how much bitrate or fps are defined in options. It already pulls 15MB/s. That's no fun and i will go back to the shiny h264 player instead.
Edit: I've setup a dual stream setup (analysis on 720p/h264, record 2160p/h265). 720p is 'modect' without any writers and h265 is 'nodect' and linked to the other stream. It seems to work even though empty events appear on the 1st stream as well. The nodect stream still needs 10 (useless?) buffers.
But the biggest problem is the jpg event player. I can't get satisfiable results with Firefox. Too laggy and low fps no matter how much bitrate or fps are defined in options. It already pulls 15MB/s. That's no fun and i will go back to the shiny h264 player instead.