Use Google to Calculate Surveillance Storage

By John Honovich, Published Jun 29, 2013, 12:00am EDT (Info+)

Manufacturer calculators are a bad crutch that can increase mistakes. They attempt to make it easy but gloss over key factors that tend to deliver wildly inaccurate results.

Here's a better way and you can use google to do it. Check this short video how:

****** **** *** ******* *** ******** estimates, ********* *** **** *** *********** bitrate.

*** ***** *******, ** *** ** not **** *** *** ***** ** your *******, *** ****** *** ** doing ************ ** ***

******* * ************ ********** ******** **** a ******* ** * ****** *** disaster ******* ** ****** **** **** you ****** **** (*********** ********, **** scene *** *** ***** *** ****** in, *** *** ****** ****** ** scene ***********, ***.). ***** *** (***** amount **) **** ** **** *** learn *** *** **** ** **** camera / ***** *** **** *** can ******* *** ****** ******** ***** Google.

*** ****, *** ******** ** *********** ******* / ************ **** **** ******** ******* ** ***** so.

Comments (5)

Actually, some manufacturers' storage calculators are pretty accurate, depending on the assumptions you plug in. For instance, both Geutebruck and IndigoVision's calculators jibed pretty well with my own calculations; in one case after I pointed out an error in their % motion assumptions.

My calculations called for ≥800TB of net storage for 960 analog inputs at 3Mbps and 240 720p cameras at 5Mbps (1120 @ 15 days and 80 @ 60 days). One manufacturer agreed with that calculation while the other claimed we needed closer to 700TB but that was based on lower % motion assumptions. When pressed with the fact that my tests of the chosen encoders revealed that their bit rates didn't vary as much as they claimed at the quality settings I wanted to see, they relented.

However, I do agree that it is wise to double-check and maybe triple-check all storage calculations. In 2003, I didn't do that. As a result, our vendor severely underestimated storage at 78TB for 896 inputs, which caused a huge discrepancy in retention times on the trial 96-camera system (3 days vs. 7 days) and resulted in a compromise where we received 170TB - only enough for ~700 inputs, and had to purchase additional storage as we added cameras.

In hindsight, it was hilarious watching the installers scramble trying to increase retention times on the trial system. They tried every trick in the book, including motion-based recording and timed recordings (which resulted in huge glitches since the encoders had to reboot every time a change was triggered) and lowering resolution and frame rates (unacceptable options). I actually enjoyed watching them squirm ;-)

By the way, a factor that doesn't seem to be generally known is how noise, "quality" and bandwidth caps can affect storage and bandwidth calculations. If you set a camera in VBR with a bandwidth cap, (for instance, Axis CBR is actually "capped" bit rate) and a high "quality" setting (80+), the actual bit rate shows little variance between scenes with high motion versus low or no motion. Noisy video has the same effect.

That is why I specified 100% motion for storage in our RFP.

Yes, Carl, this is what I was alluding to in the statement, "what scene you are using the camera in, how the camera reacts to scene differences." We cover this in the Guide on Calculating Storage / Bandwidth.

As for using a high quality setting with a cap not producing much variance between high and no motion scenes, it is likely that the high quality setting demanded a minimum bit rate that was quite close to the cap you set.

As for some manufacturer's calculators being 'pretty accurate', just because your results were close does not mean they are accurate in general. The average output is likely to be far off from the actual though in some instances it will be close and in others much far off. My point is that manufacturer calculator outputs are a crapshoot, and it's hard to be confident if your result is accurate, unless you carefully test your assumptions up front (understanding the real bit rate consumed of your streams, etc.).

I agree. In essence, following bit rate calculators' default settings is a big mistake in at least some applications. As with anything, YMMV ;-o

useful info thanks

Login to read this IPVM report.
Why do I need to log in?
IPVM conducts reporting, tutorials and software funded by subscriber's payments enabling us to offer the most independent, accurate and in-depth information.
Loading Related Reports