Limiting framerate for network cameras

[MJN]

Hi guys,

I've got a question regarding limiting capture framerate for network (IP) cameras. The docs have this to say on the subject:

[...] Note for IP cameras: ZoneMinder has no way to set or limit the mjpeg stream the camera passes, some cams you can set this through the url string, others do not. So if you're using mjpeg feeds you must NOT throttle here at the server end, only the cam end. If you want to use this feature, the server to throttle, then you MUST use jpeg instead of mjpeg method to get picture from the camera

I am using Panasonic BL-C1 cameras in mjpeg streaming mode and get a native framerate of around 8fps however I would like to limit this to 4fps to cut down overhead (CPU/disk). The cameras do not support throttling at their end and so in light of the above I apperently must switch to jpeg ('snapshot' in Panasonic speak) mode however the Panasonic developers docs say that snapshot mode should be used for one frame every 3s minimum (i.e. 0.3fps), even if it might work at faster rates, performing HTTP GET requests at 4 cycles per second seems quite an overhead all round.

Despite the advice/instruction in the ZM docs I have set ZM to a 4fps capture rate whilst leaving the cameras in mjpeg mode and it all seems to work without an issue insofar that the framerate is limited and stablises at around 4fps and everything appears to work fine. Network utilisation by the camera streams remains the same, as you would expect, and so I can only assume ZM is just dropping the nugatory frames it receives.

Can anyone shed any light on why the docs say that throttling must not be done at the ZM end when using mjpeg feeds (particularly it appears to be working)?

Regards,

Mathew

[MJN]

Network utilisation by the camera streams remains the same, as you would expect, and so I can only assume ZM is just dropping the nugatory frames it receives.

Ah, I think I may have to stand corrected on this assumption.

Using iptraf to show the packet throughput it seems that for those cameras where I have got ZM to throttle the framerate the network utilisation is far more bursty rather than a constant throughput as per the un-throttled cams i.e. it would seem that ZM doesn't just receive the whole mjpeg stream, with all the frames present, and drop the ones it doesn't want/need when asked to throttle....?

Mathew

[jameswilson]

it wont work long term. If your using mocord ore record mode you can use skip frames to lower the space requirement, but if you want to limit the fps in mjpeg it has to be done at source or use jpeg mode as you have noted.

[MJN]

Hi James,

it wont work long term.

Can you elaborate on that? It seems(!) to be working for me, although I must confess it's only been a few hours worth of testing. By not working long term do you mean it may/will cause me issues (that I've yet to observe) further down the line?

Perhaps I should just leave it to max out anyway - the machine is fairly new and coping well so the extra frames may well be beneficial afterall. I think if anything one of my issues is that the framerate seems to vary between cameras at different times - on what basis I don't know - and so things like pre/post buffer sizes, being in units of frames, end up giving different durations (in time).

Regards,

Mathew

[jameswilson]

the issue you will have is that you will jump in recored time. ie you will loose 30 seconds on an event. Easy way to tell is to run in mocord mode and see the time jumps.

[MJN]

Thanks James. I can't seem to reproduce that problem but it sounds bad enough that I'll take your word for it and stay well away!

Thanks again,

Mathew