Network Bandwidth
Aggregate stream load for a camera set, split into recording and live view, with uplink sizing for the access and distribution layers.
Planning estimates only. This calculator is not a substitute for engineered design or manufacturer specifications. Verify the final design against OEM documentation and the codes your authority having jurisdiction enforces.
The formula
Exactly what the calculator computes, in the order it computes it. Highlighted terms are your inputs.
// Recording path — every camera streams to the recorder continuously recording = bitratePerCamera × cameraCount // Live view — independent of recording, additive on a shared link liveView = viewers × tilesPerViewer × streamRate streamRate = substream rate if multi-tile view uses it, else main stream total = recording + liveView // Link sizing — never design to line rate required = total ÷ utilisationTarget uplink = smallest standard link ≥ required // Access layer, per switch accessLoad = bitratePerCamera × camerasPerSwitch
What it assumes
Each of these is a way the number can be wrong for your job. Read them before you buy hardware.
- Recording and live view are additive. True when both traverse the same link, which is the normal case for the recorder uplink. If your live clients pull from a separate distribution server on a different path, the two figures should be sized separately.
- Every camera streams continuously to the recorder. Even on motion-only recording, most deployments keep the stream up for analytics and live view. If your cameras genuinely stop streaming, scale the recording figure by the duty cycle.
- Multi-tile live view is assumed to use the substream when you select that option. If a client pulls sixteen main streams to fill a video wall, bandwidth rises by roughly an order of magnitude. Verify what your VMS client actually does — several will silently pull main streams on a single-tile expand.
- Protocol overhead is not added. The stated bitrate is the encoded video payload. RTP, UDP, IP, and Ethernet framing add roughly 5–10% on top. The utilisation target absorbs this, which is part of why you do not design to line rate.
- Peak, not average. Bitrates on VBR streams spike well above average on scene changes, and I-frames across many cameras can align. The utilisation headroom exists to absorb that.
- Multicast is not modelled. If multiple clients view the same stream over multicast, live view bandwidth does not multiply per viewer. This calculator assumes unicast, which is the conservative and more common case.
- No PTZ, audio, edge-recording sync, or firmware traffic. Camera firmware pushes and edge-storage backfill can saturate a link at times you did not plan for.
- Switch backplane capacity is not checked. A switch with enough ports is not necessarily a switch with enough fabric. Check the non-blocking throughput figure on the datasheet.
Questions people ask
- How much bandwidth does an IP camera use?
- Typically 1 to 8 Mbps per stream, depending on resolution, frame rate, codec and scene activity. Live viewing adds a second stream on top of recording.
More video surveillance tools
- Pixel Density Will this camera actually do the job at that distance? Pixels per foot and per metre, classified against the standard detect / observe / recognise / identify tiers.
- Lens / Field of View Solve for focal length, angle of view, scene width, or distance given the other three. The diagram updates as you type.
- VMS Storage How much storage this camera set actually needs for the retention you promised, with headroom.
- RAID Capacity and Retention Usable capacity of a recorder or storage array by RAID level, how many drive failures it survives, and how many days of video it actually holds.
Need it designed, installed or maintained?
We design and maintain these systems for federal facilities. Bring us the drawings.