Can I avoid re-compressing?

Forum for questions and support relating to the 1.24.x releases only.
Locked
ewildgoose
Posts: 1
Joined: Sat Jun 26, 2010 3:39 pm

Can I avoid re-compressing?

Post by ewildgoose »

Hi, new user looking to add a couple of cameras to record activity around my office (mainly at night actually). The chain of thought goes something like:

- I have avoided fitting something for some time now because having seen the quality of a VGA camera it really doesn't seem that they add any real value to identifying miscreants unless you can use a really tight zoom on a small area.

- These new megapixel cameras seem like a huge improvement in image quality, but processing that data seems like a challenge?

- I really want to minimise storage requirements so my needs are something like 1fps normally (or less) rising to 5-15fps on detection of movement. Storage will be on some of the spare storage in the office servers (admittedly need to give some further thought to someone breaking in and stealing the storage...)

- So having narrowed down affordable cameras to either the Acti 1231 (1.3mpix) or the Vivotek IP7361 (2mpix) it seems sensible to try and leverage the features of the camera to do movement detection and mjpeg/mpeg4 compression?

So, assuming I can make the cameras work as advertised, can Zoneminder be used to literally take a precompressed stream from the camera (with variable framerate) and the camera's reports of alert activity (via an http request) and save down the stream without recompressing it? And still use the alerts to give me quick highlights of things that have changed?

I guess this is a question on how ZM is really handling the underlying recordings?

Thanks for any pointers to documentation or clarification?
jfkastner
Posts: 74
Joined: Wed Jun 17, 2009 11:52 pm

Post by jfkastner »

i had a similar thought but you gotta re-write main parts of ZM

problem is: the JPG from the cams need to be de-compressed for analysis - to detect motion or detect a dark/nonworking cam

then ZM outlines the motion of the pic - and thus referres to past pics to reference the change in the pic

then it needs to re-compress the pics to send them to either a browser or storage

so thinking about it - there's NO avoiding the de/re-compress 'workflow' - unless you would stream let's say BMP or another uncompressed format and save this as well

you could try setting the JPG quality to 100% etc and see how this affects your system load - bigger files and less compression, also check different palettes - my USB cams work better/quicker with YUV

also install the JPG - SIMD libraries (search the forums, there's a detailed guide) to lower cpu load
Locked