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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.