Resolution vs Bitrate vs Frame Rate: What Actually Drives CCTV Bandwidth
Why resolution alone doesn't determine network bandwidth, how frame rate scales bitrate roughly linearly, and which of the three settings to adjust first when a bandwidth budget is tight.
Published July 15, 2026
“4K cameras” tells you almost nothing about actual network bandwidth on its own — resolution, bitrate, and frame rate are three separate settings that interact to determine real bandwidth consumption, and confusing which one is actually driving your numbers leads to both over- and under-provisioned networks.
Three settings, one bandwidth outcome
How many pixels each frame contains — more pixels means more raw data before compression.
The actual, directly-configured data rate the encoder targets — the number that goes straight into a network bandwidth calculation.
How many frames are captured and transmitted per second — more frames means more data to encode per second.
The critical thing to understand about network bandwidth specifically is that bitrate is the number that actually matters for the Network Bandwidth Calculator — resolution and frame rate are inputs that influence what bitrate a camera needs to achieve a given visual quality, but they aren’t themselves the bandwidth figure. Two cameras at identical resolution and frame rate can still have different bitrates depending on quality settings, codec, and scene complexity — which is exactly why “resolution alone” is an unreliable way to estimate bandwidth.
Why resolution isn’t a direct proxy for bandwidth
Doubling resolution ≈ 4× the raw pixel count (both dimensions double)
But compressed bitrate scales less than proportionally, since compression efficiency and scene redundancy both affect the real relationship.
Doubling a camera’s linear resolution (say, from 1080p to 4K, roughly doubling both width and height) means roughly four times as many raw pixels per frame — but the compressed bitrate needed for comparable visual quality doesn’t scale by exactly that same 4x factor, because compression algorithms exploit spatial redundancy within a frame more effectively at higher resolutions, and scene content (not just pixel count) genuinely affects how much data compresses well. This is exactly why manufacturer-recommended bitrates for higher-resolution cameras, while genuinely higher than lower-resolution equivalents, typically don’t show a clean, precise 4x jump — the real relationship is meaningfully sub-linear.
Frame rate: a more directly proportional relationship
Frame rate’s relationship to bitrate is closer to proportional than resolution’s, since each additional frame per second genuinely adds a comparable additional amount of data to encode — though compression between consecutive frames (which exploits similarity from one frame to the next) means the relationship isn’t perfectly linear either. Halving frame rate (say, from 30 fps down to 15 fps) is a commonly used, genuinely effective way to meaningfully reduce bitrate for scenarios where smooth, high-frame-rate motion isn’t essential to the camera’s purpose.
Many CCTV deployments deliberately run at 15 fps rather than 30 fps specifically because most security and evidentiary purposes don't require smooth, high-frame-rate motion the way live broadcast or gaming might — 15 fps is generally sufficient to clearly identify what happened in a scene, making it a common, practical bandwidth-saving choice rather than a compromise on genuinely necessary quality.
Which setting to adjust first when bandwidth is tight
| Setting to reduce | Typical bandwidth impact | Typical quality tradeoff |
|---|---|---|
| Frame rate (e.g., 30 → 15 fps) | Meaningful, fairly predictable reduction | Less smooth motion; usually acceptable for security purposes |
| Bitrate/quality setting directly | Direct, immediate reduction | More visible compression artifacts at lower settings |
| Resolution | Significant reduction, but a bigger visual quality change | Reduced detail, especially for zoomed or cropped review |
For most CCTV bandwidth-tightening scenarios, reducing frame rate is often the most favorable first adjustment — it produces a meaningful, predictable bandwidth reduction while preserving full resolution detail for reviewing any individual frame, which matters more for identification purposes (a face, a license plate) than perfectly smooth playback motion does. Reducing resolution directly is generally the adjustment of last resort, since it directly reduces the fine detail available in every single frame, not just the smoothness between frames.
A practical example combining all three
Same Bitrate Target, Different Combinations
4K @ 15fps and 1080p @ 30fps can land at genuinely similar bitrates, despite very different resolution and frame rate settings.
This is exactly why two cameras with very different resolution and frame rate settings can still need similar network bandwidth: a 4K camera at 15 fps and a 1080p camera at 30 fps might both be configured to target a similar bitrate, trading resolution for frame rate (or vice versa) while landing at a comparable bandwidth requirement — a genuinely useful flexibility for tuning a camera to its actual purpose (detail-focused vs. motion-focused) within a fixed bandwidth budget.
Sizing your network from the number that actually matters
The Network Bandwidth Calculator needs each camera’s actual configured or rated bitrate directly, not its resolution or frame rate setting — checking each camera’s real bitrate specification (from its configuration interface or spec sheet) rather than estimating from resolution alone is the reliable way to get an accurate bandwidth total, regardless of which specific combination of resolution and frame rate a given camera is configured to use.
FAQ
Does a 4K camera always need 4 times the bandwidth of a 1080p camera? No — while 4K has roughly 4x the raw pixel count of 1080p, compressed bitrate scales less than proportionally, so real-world bitrate differences are typically meaningfully smaller than a straight 4x factor.
Is reducing frame rate a good way to save bandwidth without losing much practical value? Often yes for CCTV specifically — 15 fps is commonly sufficient for security and identification purposes, making frame rate reduction a favorable first lever compared to reducing resolution.
Can two cameras with different resolutions have the same bitrate? Yes — bitrate is a directly configured (or rated) setting, and different resolution/frame rate/quality combinations can be tuned to land at a similar bitrate despite different resolution settings.
Should I estimate network bandwidth from a camera’s resolution? No — always use the camera’s actual configured or rated bitrate for network bandwidth calculations, since resolution alone is an unreliable proxy for the real data rate.
Does reducing resolution or frame rate affect storage the same way it affects network bandwidth? Yes, in the same direction — since storage sizing is also driven by bitrate (as covered in CCTV storage calculations), the same resolution/frame rate/bitrate relationships that affect network bandwidth apply equally to storage consumption.
Is there a “correct” frame rate for CCTV? It depends on the specific purpose — 15 fps is a common practical default for general security monitoring, while scenarios specifically requiring smoother motion capture (tracking fast-moving objects, for instance) may justify a higher frame rate despite the bandwidth cost.
Whichever settings you land on, remember they interact with motion-triggered versus continuous recording — the same bitrate figure behaves differently depending on which recording mode is active.