Storing progressively degraded survelliance video

I was wondering if there was a scheme where you could store footage from a 24 hour streaming webcam so that the last 24 hours of footage is stored at 30fps, the next 24 hours is stored at 15fps, the rest of the week gets stored at 5 fps and then the rest of the month is stored at 1 fps. As you continue shooting, the footage gets continually degraded.

By my calculations, this works out to be about a cumulative of 3 days worth of full footage. If you assume you can compress it using something like DivX down to 500Mb per hour then it would require about 40Gb to store a months worth of footage and another 60Gb to store the rest of the year at 0.5fps. Seeing as consumer hard drives are down to ~500Gb for $100, this scheme would make it highly practical to build my own home survellience system very cheaply.

Is there any software on the market that can do this now? If not, are there any codecs that would support such a method of storing video?

I would think that constantly recoding the video to drop framerate would be so processor intensive that I would be just cheaper to buy alot of hard drives.

Sure, it can be done.
A scheme VERY similar to yours is already in use in industry.
The Lanex Company, now a division of Verint, has produced 3 models that do what you’re discussing.
Those models are:
microDVR
netDVR
netDVR II

Some of their pre-millenial products don’t support what they refer to as “thinning”, but all the current ones do. Depending on what bundle you buy, you may need to buy a license to unlock certain aspects of the “thinning” feature, especially the one where it dumps all non-motion images.

Not a problem at all.
Dedicated-use DVRs offload video processing to video capture or framegrabber cards that handle the processing.
One of the windows systems I support can record 128 frames per second and keep its Pentium IV processor below 10% load all day long. Incidentally, the 128 frames per second are 4FPS times 32 video channels.

I don’t know beans about available codecs specifically, but from a systems-design POV the idea is sound.

I suggest you’d end up doing the recoding in batches, not continuously. Say the original recording wrote to a file for 30 minutes before closing the file & switching to a new one. One approach would then be to have another process come along and rework the 30-minute file that just became 24 hours old.

My suggestion would be to take a more batch-oriented approach to archiving where in addition to reducing frame rate we combine files for ease of storage. This would have the side effect of keeping the data between 24 and 48 hours ago still at 30 fps as we transition from a continuous process to a more calendar-day-oriented process.

e.g. After midnight I’d take the calendar day 2 days prior and recode & combine the day’s files into a single file (i.e. at 0005 on Wed rework all 48 camera file chunks from Monday into a single new file named Monday recorded at 5 fps). This would reduce the quantity of 30 fps data on hand from 48 hours-worth to 24 hours-worth. Over the next 24 hours it will reaccumulate up to 48 hours total & then we trim it back to 24 again. Repeat daily ad infinitum.
Do something similar at the start of each week: If Monday is the start of your week, on Tuesday at 0105 gather the day files from Monday 15 days ago to Sunday 9 days ago & recode at 1fps into a single file for the week.

Use the same idea for the week-to-month & month-to-year transition. In each case you’ll have a little more data laying around in a larger format than if you somehow recoded continuously, but that’s a small price to pay for having a plan that you can actually pull off.

Also, because weeks & months and years aren’t uniformly meshable units of time, I’d choose to use 13 4-week intervals instead of the traditional months. Much easier.

Or bag the combining beyond days & simply shrink each appropriate day file when it becomes old enough.
As I said at the outset, I have no knowledge of codecs. But if they work anything like still-image file formats, you don’t so much need a special codec as simply some custom code to open a file using a codec that understands the file format, reset the desired frame rate (or equivalently, jettison every 1 of n frames for various n values) & resave the file using the same dumb codec.

If you’re a programmer this is easy. if you’re hoping for something you can do with some consumer video editor, I’m not optimistic.

I also don’t agree with Captain_G’s concerns. This is not that intensive. We’re just jettisoning frames. Every midnight we make a 6-to-1 cut (30fps to 5) converting 24 hours to 1 day. Once a week we make a 5-to-1 cut (5fps to 1) of 7 days into a week. Once a month we make a 2-to-1 cut (1 fps to 0.5 fps) of a month’s worth. The ~exponential decay of frame rate means the actual number of frames is easily handled at each step.

Ooops. Forgot to answer the OP on this one.
I don’t know if there are any Codecs that do what you want.
It might be more efficient to actually record the same footage in three clips:
Make one clip the nice copy, delete first
One medium clip, delete in middle
One crappy clip, delete last

Incidentally, I suggest using an embedded-system DVR rather than one running Windows.
You might be surprised how cheaply these can be had.