Calculating surveillance bandwidth is complex, and inexperienced users can easily underestimate bandwidth, leading to reduced storage durations and/or overloaded networks.
The most common way technicians estimate storage is to use manufacturer or third party calculator tools. However, these tools are too simple for the complex factors impacting bandwidth / storage, a fundamental flaw which fails to reflect real world conditions. In this tutorial, we explain these key issues and give our recommendations for how to most accurately calculate surveillance storage needed.
Most Use Calculators, Despite Issues
Despite their high potential for inaccuracy, most people use calculators. They are simple to use for even novices, typically asking only for a few basics such as number of cameras, resolution, frame rate, with an estimate immediately generated.
From an IPVM member survey, here is the breakdown on preferred method, with a strong majority using storage calculators:
However, it is nearly impossible for calculators to reflect the wide range of conditions in which cameras are installed, as well as the variances between camera models. For example, we asked users how much bandwidth a 1080p H.264 camera uses. Notice how widely bandwidth estimates vary, even using the same resolution, framerate, and CODEC:
All of the respondents could be 'right' even though the answers vary by more than 300%. Differences in cameras used and sites deployed can easily result in massive differences in actual bandwidth/storage consumed. Calculators do not reflect them.
FYI... Axis has a newer tool called Site Designer that actually has unique setups for their newer cams etc. that are not well represented in the tool described above.
For example...the Zipstream cams are there and you can play with the settings for that to see the bitrate changes. Be sure to change the Motion amount as you change the zip effort settings because more motion negates Zip savings. One still must plan for a Max BW in your server selection but the 'potential' storage savings are there depending on the scene and motion combo.
http://sitedesigner.axis.com is the place.
If you register it will even keep a project in history for you.
What I like... the 'scene selections' are very good and represent what is discussed in this article.
There are so many other variables other than just scene complexity and megapixel output of the individual camera behaviors. Storage: 45 days versus 2 years, 75 cameras versus 400. Dual retention of a single camera - Stream A 90 days @ 2mp, Stream B 730 days @ 720p times 400 cameras. Audio, pushed video and insufficient lighting are also culprits we all love.
I had to build my own calculator in excel, the constraints and trade offs were found while applying a percentage of storage overhead so the we don't over crowd the frying pan and blow the circuit breaker. I have loading many other camera calculators to see how they scale with mine and different calculators are all over the map. So yes cameras are all unique, find your baseline and thresholds before pulling the trigger.
Great article and comments, all! There are many studies on scene types and object behavior that contribute to increased bitrate; some of the biggest contributors cited in these studies, one of which I'll give the link for, are listed below:
Are the objects in the scene moving in random directions?
Are there abrupt changes of motion, light or even network availability?
Are there big differences in motion paths and object sizes that require detection or visual acuity in the scene?
Finally, are there abrupt changes to network requests of the device (especially important consideration if you require faster on-board processors).
Finally, one of the areas that might be unrelated, but can be important was actually covered in a previous IPVM article on camera power-up times to when it is streaming.
Here's a pretty technical study, but it does contain a list of complex video scene use cases (table 1 page 6):