Why bandwidth load belongs in the camera specification, not the network team's inbox
A conference camera body is small and its spec sheet is short, which makes it tempting to treat network load as somebody else's problem. In practice the camera's own parameters decide the load: sensor resolution, the frame rates it can output, the codec it encodes with, how many streams it emits at once, and whether it also passes audio and control over the same link. Getting these numbers into the sizing conversation early is the difference between a room that runs for years and one that stutters the first time three cameras and a laptop share a switch.
This guide works through the arithmetic and, more importantly, the assumptions behind it. The framework follows how the topic sits in this category — size and configuration — so the goal is a defensible load figure with stated units and stated limits, not a single magic number.
The base formula and what each variable actually means
Video bandwidth is not one number. Model it as a sum of streams:
- B_total (Mbps) = sum over all streams of (stream bitrate × protocol overhead factor), plus control and audio overhead, plus a headroom factor.
- Stream bitrate (Mbps) = bits per second the encoder emits at the selected resolution, frame rate, codec and motion setting. This is the dominant variable and the one spec sheets most often leave vague.
- Protocol overhead factor = multiplier covering transport and packetisation. Realtime streaming with RTP/UDP or SRTP typically adds a few per cent; TCP-based transports and tunnelling add noticeably more because of retransmission and encapsulation. Treat it as a multiplier you justify, not a constant you assume.
- Frame rate (fps) enters twice: directly in the camera's output configuration, and indirectly because encoders at a fixed target quality will raise bitrate as frame rate rises at constant resolution.
- Headroom factor = spare capacity for bursts, keyframes and concurrent file or firmware traffic. A practical starting point is to plan links and uplinks for the sustained load plus a healthy margin, and to remember that a link running near saturation is where latency spikes appear.
Frame rate is also a procurement trap. Many cameras list a maximum frame rate at reduced resolution, or list 4K at 30 fps while only offering 60 fps at 1080p. Two cameras quoting "4K" can therefore carry very different loads. Always pair the resolution with the frame rate in the same row of the specification table before you compare bitrates.
Reference bitrate anchors and how to scale them
Publishing bitrate guidance for H.264 and H.265 encoders is reasonably consistent: 1080p at 30 fps is commonly delivered in the 8–16 Mbps range with H.264, and H.265 reaches broadly comparable visual quality at roughly half that bitrate. Higher frame rates and higher resolutions scale up substantially, and 4K streams at 30 fps are commonly planned in the tens of Mbps with H.264.
For conference rooms, those delivery numbers are a ceiling rather than a target. A typical room camera feeds a codec or a videoconferencing platform that will re-encode, and a 1080p talking-head shot compresses far better than the motion-heavy content the delivery guidance anticipates. Two consequences follow:
- Do not size a room network from a 4K file-delivery number. Size it from the camera's configured output stream, then add margin.
- Do not promise quality from bitrate alone. Two cameras at the same bitrate can look very different because of sensor size, lens quality, noise reduction and encoder implementation. Bitrate sets the budget; the optics and sensor set what the budget buys.
Transport choices set the real ceiling: NDI versus NDI|HX and baseband outputs
Where the camera output is IP-based, the transport matters more than the codec label. Compressed NDI variants are commonly described as requiring on the order of 8–20 Mbps per 1080p stream, rising to roughly 80–120 Mbps for 4K depending on the variant and codec. Full high-bandwidth NDI is in a different class altogether — on the order of 125–150 Mbps for 1080p and several hundred Mbps for 4K — and needs a gigabit backbone, with 10GbE sensible once several such streams converge.
That has a direct configuration consequence that is easy to miss when ordering hardware: a 100 Mbps access port is adequate for a compressed 1080p stream and inadequate for a 4K compressed stream whose peaks approach the port's capacity. A camera can be perfectly specified and still be crippled by the switch port it lands on. Write the port speed requirement next to the camera in the bill of materials, not in a separate networking document nobody opens.
Baseband outputs sit outside this calculation. HDMI and 3G/12G-SDI carry video plus embedded audio over a cable with no shared-network contention, so they are not subject to the stream arithmetic at all — but they do impose their own configuration limits (cable length, connector locking, and the resolution/frame-rate combinations the interface supports). Many professional 4K PTZ cameras offer simultaneous HDMI, SDI and IP outputs, which means one camera can add network load through IP while feeding a local switcher over SDI. Count only the streams that actually share the network.
A worked room-level estimate
Consider a mid-sized room with three cameras, each configured for a 1080p stream at 30 fps, with one of the three also sending a second lower-resolution stream for preview. Assume each primary stream is configured at 6 Mbps, the preview at 2 Mbps, protocol overhead of about 3–5 per cent, and a headroom target of 30 per cent for bursts and control traffic.
- Primary streams: 3 × 6 Mbps = 18 Mbps.
- Preview stream: 2 Mbps, giving 20 Mbps of payload.
- Protocol overhead at 5 per cent: 20 × 1.05 = 21 Mbps.
- Headroom of 30 per cent: 21 × 1.3 ≈ 27 Mbps of sustained link capacity to plan for.
Now repeat the same room with 4K compressed streams: 3 × roughly 80 Mbps already exceeds 200 Mbps before overhead, which means gigabit switching on the camera VLAN and a serious look at uplink and recording capacity. The arithmetic did not change; the configuration did. That is the point of doing it as a table rather than a sentence.
Frame rate, motion and the quality you are actually buying
Frame rate decisions are usually made for reasons unrelated to bandwidth: 60 fps makes motion look smoother on large displays and can help with automated tracking, while 30 fps halves the encoding burden for static meeting content. The trade-off to document is that higher frame rate raises bitrate at a fixed quality target, and that raising frame rate while keeping bitrate fixed pushes the encoder to discard detail — visible as softening in hair, fabric texture and text on whiteboards.
For a room where the primary content is people speaking, a well-lit 1080p stream at 30 fps is usually a better use of a bitrate budget than a 4K stream squeezed into the same budget. If the room must support whiteboard capture or detailed presenter movement, budget the resolution and frame rate together and check the result on a real display at real viewing distance instead of trusting the specification table.
Configuration checks before sign-off
- For each camera, record resolution, frame rate, codec and configured bitrate as a single row; mixed rows are not comparable.
- Confirm the number of simultaneous streams the camera can emit, and whether enabling a second stream degrades the primary one on that model.
- Match every IP-output camera to a port speed that exceeds its configured peaks, and verify PoE budget if the port also powers the camera.
- Confirm whether audio and control travel in the same stream or separately, and add that traffic to the total.
- Test with all cameras live plus a recording or conferencing session running, because single-camera tests systematically understate load.
- Re-run the sum after any firmware update that changes encoder defaults.
Limits of this calculation
The formula produces a planning figure, not a guarantee. It cannot tell you what a specific encoder does under complex motion, how a third-party platform will transcode the stream, or what your access points will deliver over Wi-Fi with clients roaming. Published bitrate anchors describe typical delivery practice and vary by implementation and scene content. For any project where the room is critical, the estimate must be validated with a live multi-stream test on the actual network, and the network design — not the camera — should carry the residual risk.