IPVM does not recommend any bandwidth calculators, not because they are all bad but because the problem is fundamentally intractable.
The issue is that bandwidth is driven by way too many complex, site specific factors to be reduced to a calculator. See: Bandwidth Guide For Video Surveillance
In particular, there are 2 critical issues for bandwidth calculators:
- Bandwidth consumption can vary dramatically across models (even from the same manufacturers and even if the resolution, frame rate and compression levels are the same). A big part of this is difference in image sensors and image processing techniques used. So a generic resolution / fps / compression level calculator (typical) will regularly be far off. Some camera manufacturers (e.g., Axis) do vary calculations based on model, and this helps somewhat.
- Seemingly small changes in scenes can result in big bandwidth differences. A 'simple' scene will need less bandwidth than a 'complex' but there's quite a range in between and, sometimes, even zooming the camera in or out moderately will cause massive bandwidth swings. See: Advanced Camera Bandwidth Test Results
IPVM recommends taking the camera models you plan to use at the site you plan to use them and doing a quick on site test / measurement. Here are some Portable Power options to do that.
Once you get real numbers with the actual camera / actual site, you can easily calculate out over any time period with simple multiplication.
On site real life tests are surely the best things to do.
In real life, when it is not possible, a simple test with a bandwidth software on a no cap VBR camera can be enough to test & approach the reality. Especially when you know that darkness (before sunrise, after sunset) is the most difficult situation for most sensors running H264. By manually shaking the camera you can simulate strong H264 movements.
Zoom like you explained in some IPVM, also create additionnal coding needs..
When you know the night limits with Res x fps x compression ratio x basic or main H264 you can set your caps on VBR or Smartstream or your fixed or overage CBR.
Smartstream is a nice way to concentrate bandwidth on the ROI and avoid peaks in Bits/Bytes. Should be interesting to compare how several manufacturers are managing this.
As John told it can vary based upon your complexity. Where as you can monitor your current streaming bandwidth using your PC network by Taskmanager->Networking bandwidth. Make sure you are not using any other app which consumes bandwidth togather with streaming media.
Also many integrators aswellas camera manufacturer's provide bandwidth on their UI for the live streams.
But if you are using VBR and if your camera provides a selection of max bitrate then ideally speking your total bandwidth for the current stream will be almost equal to your max bandwidth set under high complexity.
Sure Sujit, but highest complexity is always a dome movement simulation, where H264 reaches its predictive limits.. with a 100% of pixel changes . This is simulated manually on fixed camera as well...
And with VLC you can measure with accuracy a specific stream and not an aggregation of bandwidth.
The UI is provided by very few manufacturers and beside, when a camera tells you it is sending 10 mbits or 25 Mbits do you think you really get it out of the network interface..? better measure it and be independant from the vendors/editors. When you software is overloaded you can 't trust what is displayed, but you might rely on a port miroring test on your Switch...that's the diffrence
Same way, do you really believe you can reach 1000 mbits on a Gbit TP ? or 300 Mbts on a Wifi link , and even more than 70 mbits on a single stream on a Fast Ethernet, Sincerely?