Can I Get Progressive Frame Reduction For Video Storage?

Note: For just the initial conceptual model I am using MJPEG, not because I need it, but because it's easy to talk about it.

I know that temporally compressed CODECS present some difficulties in doing it exactly the same way, though I have some ideas how to overcome them.

If there are no show-stopping reasons for MJPEG I am ready to move to the present day case and talk about h.264, but I want to make sure there are no logical problems first.

Anyway, it seems that the normal method of either having video because you are in the retention period or not having it, is possibly not the best use of storage.

Of course I realize that many systems are driven by corporate or government spec of "must retain video for X days". Still this X days concept is usually not connected to a use case scenario. Sometimes it is of course, e.g. maybe a retail establishment needs to keep data around until a check would clear, and so maybe 7 days makes sense.

In most cases though I think it's just a gut based on storage vs dollars and driven by the systems capability.

But I think a better way for some would be a dynamic data pruning system based on reducing the frame rate progressively over time as the data ages.

For me I would find it far more valuable to have the whole year of 2015 at one frame a minute than one more day at 30fps.

So it would work like this possibly, for a given time period, let's say a month, the frames per second would halve.

So

  • week 1 = 30 FPS
  • week 2-3 = 15 FPS
  • week 4-7 = 8 FPS
  • week 8-15 = 4 FPS
  • week 16-31 2 FPS
  • week 32-63 1 FPS
  • week 64-127 30 FPM
  • week 128-256 15 FPM

So you would have some level of video for 4 years, or 8 weeks at 30 FPS.

Is this crazy?

edit: I am aware that many VMS allow pruning data by reducing FPS, but the ones I have seen are not progressive.


Time sight.

https://m.youtube.com/watch?v=RNBz7a9R4Ag

Failed

Yes, I'm familiar with them. To be clear, I don't want to start a company to manage this, just would like it as a feature on a platform. Also, it I believe whatever benefit there might be, quickly erodes when you start talking about transcoding streams, in the absence of SVC at least.

Also, Timesight's emphasis was on transcoding, and in my scenario I think continually recompressing streams would be quite ridiculous.

Thats why I'm not proposing that but rather just selectively deleting data, which should take far less processing, and is something done by the VMS at some point anyway.

In some particular cases, maybe, but for most of them it does not make sense because so law frame rate makes it useless as an evidence and source of information for investigations.

...for most of them it does not make sense because so low frame rate makes it useless as an evidence and source of information for investigation.

I think you may be overstating that a tad. How is a license plate of car in a parking lot captured at 1 FPS useless as evidence, or the make and model, or what time someone left the building etc?

Nothing per se about the framerate invalidates the evidence, and of course still photos (in the extreme case) are admissible just as movies.

Consider a typical employee shrinkage problem, the kind that might not get detected for months. Assuming that there was incriminating evidence at the originally recorded 30 FPS, don't you think the chances are pretty good that there will still be evidence at 1 FPS?

At least a better chance than if you have 0 frames per second. And what did you give up for being able to look back months earlier? A few days of 30 FPS.

Related I'm not sure if VMSes have a feature where you have a longer retention period for the video with motion etc, but that would be helpful.

You cannot be sure that you will get this frame with a license plate number or an offender face by decreasing fps on a raw video (there are good comments from U3M and John below), with 1fps you won't also be able to analyze actions (who started the fight?).

If customer needs in license plates, faces, actions then it can be recorded (event recording) and it can help to save storage without transcoding. If customer can use 1fps video for its purposes then he can store video with 1fps from the beginning.

I think that at such a low frame rate, you will be annoyed that you didn't capture the evidence, and you should know about certain issues before 1 year passes.

At 1 fps, getting the plate of an offender is unlikely.

Also, the processing power to continously transcode the video is enormous and you will progressively lose quality.

Instead, if you have a need for 365 days of 1 fps, put in a second recorder and send another stream to that recorder. Nice and simple, mjpeg.

This way you don't play the game of "I though we hadon't video showing xyz", but now I don't see it....

1, what you want makes sense.

The problem with H.264 is how I frames are used. It is simple to go from full recorded frame rate (whether it is 30, 15, 10, etc.) down to just I frames. All the p or b frames are dropped and you just have essentially a MJPEG stream remaining, at whatever rate the I frames were.

What you want to do is more complicated with H.264, or H.264, or MPEG-4. To go from 30 to 15 to 8 fps, you would need to drop some 'b' or 'p' frames but this cannot be simply done with an existing stream.

That is why a few VMSes offer transcoding to accomplish what you want (e.g., TimeSight discussed above).

Overall, somewhat costly to do, in terms of computing resources and other ways to reduce storage costs over time.

What you want to do is more complicated with H.264, or H.264, or MPEG-4. To go from 30 to 15 to 8 fps, you would need to drop some 'b' or 'p' frames but this cannot be simply done with an existing stream.

Not historically, but both Hik and Dahua have been shipping SVC-T enabled cameras for over a year now.

So theoretically it could be made to work on those cameras, no?

Our understanding is that this is not really supported. Feel free to test it on yours.

Ok, and I agree it's not worth doing any real transcoding.