Page 1 of 1

How to minimize ZM disk space consumption

Posted: Fri Sep 01, 2006 8:55 am
by rchurch
I am trying to reduce the file space used by ZoneMinder to allow more days to be saved.

The steps I want to use are:

1. Create the mpeg

2. Delete all the jpegs

3. Change Links to jpeg playback to point to mpeg file


Is there a way of doing this without zmaudit.pl deleting the event records from the database?

I also generated an mpeg from jpegs recording at 4 frames per second, and the whole video was smeared.

Is there a work around for this?


rchurch

Posted: Sat Sep 02, 2006 12:48 pm
by rchurch
Bump?

Posted: Sat Sep 02, 2006 1:02 pm
by jameswilson
you can create the mpeg but there is no way to make zm playback the mpeg not the jpegs and as you have found if you delete the event it will remove the db entry. If i wanted to do this i would look at a seperate application to do this, but there would be no db link. I would create the mpeg and save it somewhere not affected by zmaudit. Delete the event and move the mpeg into a dedicated file structure, ie /var/mpegs
then have a folder per day then store each event in here using the time as the file name. Im sure this is possible with a script but id look at using realbasic or gambas if i were to do this

Posted: Sat Sep 02, 2006 2:09 pm
by rchurch
My idea is to create a small highly optimised jpeg for each image, or even fewer images which display a message indicating where the mpeg can be downloaded from.

In fact it could be nice if zm could transparently handle the case where all the jpeg files could be replaced by links to the same image.

What I also wonder if the number of jpeg files can be reduced without affect ZM's operation that much, so long as the event folder and its entry in the database are not affected.

I mean if all but one of the event files were deleted and zmaudit.pl deleted all the files but one, how would that affect zm's operation? I have a feeling that besides the information related to the deleted files from the database everything should be fine?

jameswilson wrote:you can create the mpeg but there is no way to make zm playback the mpeg not the jpegs and as you have found if you delete the event it will remove the db entry. If i wanted to do this i would look at a seperate application to do this, but there would be no db link. I would create the mpeg and save it somewhere not affected by zmaudit. Delete the event and move the mpeg into a dedicated file structure, ie /var/mpegs
then have a folder per day then store each event in here using the time as the file name. Im sure this is possible with a script but id look at using realbasic or gambas if i were to do this

Posted: Sat Sep 02, 2006 2:12 pm
by jameswilson
that would need a mod to zm audit. You could put the link the mpeg in the notes of the event i suppose

Posted: Sat Sep 02, 2006 2:29 pm
by rchurch
How does zmaudit handle deleted files - I mean the jpeg files themselves, not the folders relating to the events?
jameswilson wrote:that would need a mod to zm audit. You could put the link the mpeg in the notes of the event i suppose

Posted: Sat Sep 02, 2006 2:33 pm
by jameswilson
rchurch im afraid i dont know, sorry i assume it just removes the directory not the individual folders but i am guessing

Posted: Wed Sep 06, 2006 5:38 pm
by zoneminder
zmaudit will remove the entire directory and all it's contents.

Posted: Mon Sep 11, 2006 7:54 pm
by rchurch
When I try to convert an image recorded at 4
frames per second in jpeg into mpeg at 25 frames per second (which a
lot of Windows mpeg players require), the result is smeared images.

I intend to get round the problem through extrapolating the jpeg
frames by repeating each jpeg image 4 or 5 times to avoid the smeaing.
What I am afraid of is that the result mpeg may be 4 or 5 times longer
and that would defeat the purpose of the whole exercise.

Is there some setting I can use that will create unsmeared images and
still be as compact as before?

As every 5 frame sequence will be identical, the encoder should be able avoid duplicating just as a zip compressor is capable of, shouldn't it?