Page 1 of 1
ZM Scalability (# cams) when recording only?
Posted: Thu Feb 14, 2008 11:24 pm
by andrewS
Hi,
I am new to ZM and wondering how many AXIS IP Camera's performing continuous recording at 1 fps (640x480) or sending clips when a motion detect event occurs (e.g. business hours, after hours) could a single ZM server reasonably handle?
I imagine this is more a bandwidth and storage issue, and not necessarily CPU intensive if the system is not parsing the images for event detection, but perhaps I'm wrong?
Also, can anyone tell me whether it's possible to set this to split continuous recording from an AXIS Ip camera into sections (e.g. 1 minutes chunks). Is this done at source (Camera) or processed by the ZM server?
Many thanks in advance, Andrew
Re: ZM Scalability (# cams) when recording only?
Posted: Fri Feb 15, 2008 1:22 am
by cordel
andrewS wrote:
I am new to ZM and wondering how many AXIS IP Camera's performing continuous recording at 1 fps (640x480) or sending clips when a motion detect event occurs (e.g. business hours, after hours) could a single ZM server reasonably handle?
Really depends on the machine you build for it. IP cams produce a bit more load as the jpeg image has to be converted to raw format. If you put together a quad core or more machine you could likely handle >240 FPS but there are really no bench marks.
andrewS wrote:
I imagine this is more a bandwidth and storage issue, and not necessarily CPU intensive if the system is not parsing the images for event detection, but perhaps I'm wrong?
For the most part that is correct. There are a few ways around both issues if you spec the machine to use right. The more busses, controlers the better.
andrewS wrote:
Also, can anyone tell me whether it's possible to set this to split continuous recording from an AXIS Ip camera into sections (e.g. 1 minutes chunks). Is this done at source (Camera) or processed by the ZM server?
This would be a function of ZM, and yes it already does it. I think the default is set to 10 minute sections and should be explained in the
documentation.
Posted: Fri Feb 15, 2008 2:14 am
by andrewS
Thanks for this. I found the reference you were talking about, and have pasted this below for anyone reading this thread.
Section Length
This specifies the length (in seconds) of any fixed length events produced when the monitor function is ‘Record’ or ‘Mocord’. Otherwise it is ignored. This should not be so long that events are difficult to navigate nor so short that too many events are generated. A length of between 300 and 900 seconds I recommended.
While we're on this discussion regarding capacity in terms of FPS, can you elaborate further on the process going on in terms of converting the feed from the IP Cams into Raw format? Is there any benefit in using motion JPEG versus MPEG4 in cameras that support both formats?
Thanks again in advance.
Posted: Fri Feb 15, 2008 3:36 am
by cordel
ZM does not handle Mpeg capture. Mpeg is also a lossy codec, streaming only the bits it thinks is changed in the picture. If you take and pause a mpeg capture, and zoom in it will also be somewhat blocky looking. Mpeg-2 is what is usually used and mpeg-4 is becoming more common.
http://en.wikipedia.org/wiki/Mpeg
Jpeg/mjpeg compression gives pixel by pixel in each frame which is really a whole jpeg picture either way, jpeg and mjpeg (mjpeg streams send whole jpeg pictures with a separator between the images so it is like an infinite file.) , the compression comes from rounding the pixel to the nearest color so that the number of colors in a jpeg are less than whats available raw so you don't need as many bits to represent a color (basically) but all the information is there in each frame.
http://en.wikipedia.org/wiki/Jpeg
http://en.wikipedia.org/wiki/Mjpeg
ZM supports IP cams and Capture devices. Capture devices feed a raw image. ZM analyzes the raw image for motion. IP cams send anything other than raw images to conserve bandwidth, so jpegs need to be converted to raw form to be analyzed.