Three dials on the same camera — and only two of them are actually settings you dial in.
Ask most people sizing an NVR how much storage a camera needs, and they'll reach for a simple formula: resolution × frame rate × some fixed bits-per-pixel number. It feels rigorous — it has units, it multiplies clean numbers together — and it's wrong in a way that can throw a storage estimate off by several times. Resolution and frame rate are settings you choose. Bitrate— the thing that actually determines how much data hits the disk every second — is not simply derived from those two settings. It's also driven by something neither setting controls at all: how much the scene in front of the camera is actually changing, frame to frame.
Resolution is how much visual detail a single frame captures, measured in pixels — 1080p, 4K, and so on. More pixels means more ability to identify a face, a license plate, or a small detail at distance, and it also means each individual frame is bigger before it's ever compressed. Frame rate is how many of those frames get captured every second, in fps. A higher frame rate produces smoother-looking motion and lowers the odds of missing a fast event that happens between two widely-spaced frames — someone running past, a vehicle passing quickly — and every additional frame captured per second is additional data that has to be encoded and stored. Bitrate is different in kind from the other two: it's the actual amount of data per second the resulting video stream consumes after compression. Resolution and frame rate both push bitrate up — more pixels per frame and more frames per second both mean more raw information to encode — but bitrate is also strongly shaped by the compression codec and quality settings in use, and, critically, by how much the scene itself is changing. A busy, high-motion scene compresses far less efficiently than a static, low-motion scene at the identical resolution and frame rate, because modern video codecs work by encoding changes between frames — more motion and complexity means more change to encode, which means more data, no matter what the resolution or frame rate dials are set to.
Modern video codecs (H.264, H.265, and similar) don't re-encode every frame from scratch. Most frames are encoded as the differencefrom the frames around them — a technique built on the observation that consecutive video frames are usually mostly similar. A hallway with nothing moving in it produces almost no frame-to-frame difference, so the codec spends very little data describing each new frame; it's mostly just "same as before." A loading dock with trucks, forklifts, and people constantly moving produces a large frame-to-frame difference throughout — there's genuinely more new visual information every frame, so the codec has to spend more data encoding it. Same resolution, same frame rate, same codec settings — very different bitrate, purely because of what's actually happening in the scene.
Resolution and frame rate describe the raw material the encoder has to work with: how many pixels per frame, and how many frames per second. Neither one describes how compressible that material turns out to be, and compressibility is what actually determines bitrate. Video codecs lean heavily on inter-frame prediction — most frames are stored as a description of what changed relative to nearby frames, not as a full standalone image. A quiet hallway changes almost nothing from one frame to the next, so the encoder spends very little data describing each new frame. A loading dock with trucks, forklifts, and people in constant motion changes substantially every frame, so the encoder has real new information to encode every single time. Two cameras can share every configured setting and still land on bitrates several times apart, purely because one of them is pointed at more change than the other.
This is false, or at best a rough starting point that can be wrong by several times in either direction. That formula treats bitrate as something fully determined by resolution and frame rate, which ignores the factor that actually dominates real-world storage outcomes: how much the specific scene each camera is watching is changing over time. Modern compression codecs encode inter-frame changes efficiently, so a static scene at a given resolution and frame rate can consume a fraction of the data a high-motion scene consumes at the identical resolution and frame rate. Accurate storage sizing for a real CCTV deployment has to account for each camera's actual expected scene characteristics — a quiet back office versus a busy loading dock, a low-traffic hallway versus a crowded lobby — not a single fixed formula applied uniformly across every camera on the system. This is exactly why variable bitrate (VBR) encoding, which lets the actual data rate float with scene complexity to hold quality roughly constant, and motion-based recording, which raises frame rate or quality only when motion is detected and drops back down during idle periods, are both standard storage-optimization strategies rather than edge-case tricks.
Explains why resolution (pixels per frame), frame rate (frames per second), and bitrate (actual data rate after compression) are three genuinely different quantities that trade off against a storage budget in different ways — and why bitrate, the one that actually determines storage consumption, is driven not just by resolution and frame rate but also by scene motion/complexity and codec settings, which is why naive resolution × fps storage formulas routinely miss real-world storage requirements by several times.
Resolution and frame rate are both simple, well-defined numbers that are easy to multiply together, so it feels natural to assume storage scales cleanly from them. In reality, resolution and frame rate only describe the raw amount of visual information the camera is capturing — they say nothing about how efficiently that information compresses. Bitrate, the actual data rate after compression, is the quantity that determines real storage consumption, and it depends on the codec and quality settings in use and, just as heavily, on how much the scene itself changes over time.
Codecs such as H.264 and H.265 rely on inter-frame prediction: most frames are encoded as the difference from nearby frames rather than as complete standalone images, because consecutive frames of real video are usually mostly similar. A static or near-static scene produces very little frame-to-frame difference, so the encoder needs very little data to describe each new frame. A scene with continuous motion produces substantial frame-to-frame difference throughout, so the encoder has to spend meaningfully more data on every frame just to keep up with what actually changed.
Because bitrate is driven by scene content as much as by settings, two cameras set to the identical resolution, frame rate, and codec/quality configuration can produce dramatically different actual bitrates depending on what each one is pointed at — a quiet hallway versus a busy loading dock is a common real-world example. This is precisely why real CCTV storage sizing has to account for each camera's expected scene characteristics rather than applying one fixed formula uniformly across every camera in a system.
Because bitrate varies with scene motion, two standard techniques exist specifically to manage it: variable bitrate (VBR) encoding, which lets the actual data rate float upward during high-motion periods and downward during static periods to hold visual quality roughly constant, and motion-based (event-triggered) recording, which raises frame rate or recording quality only when motion is detected and drops to a lower rate or stops recording entirely during idle periods. Both exist because fixed-rate assumptions about storage consistently fail to match what busy scenes actually require.
For the same scene, frame rate, and codec settings, yes — more pixels per frame is more raw information for the encoder to describe, which generally increases bitrate. But resolution alone does not determine the final bitrate value; scene motion and codec/quality settings shift it independently, sometimes by a larger margin than the resolution change itself.
Not exactly, and rarely proportionally. More frames per second is more data to encode, but consecutive frames captured closer together in time tend to be more similar to each other, which inter-frame compression exploits — so storage typically increases with frame rate, but by less than a naive linear multiplication would suggest, and the actual increase still depends on scene motion.
Because modern video codecs primarily encode the differences between frames rather than re-describing every pixel from scratch each frame. A high-motion scene has genuinely more new visual information changing from frame to frame, so the encoder needs more data to represent those changes accurately — independent of what resolution or frame rate the camera is set to.
VBR lets the encoder's actual data output rise and fall with scene complexity in order to maintain a consistent visual quality target, rather than holding the data rate perfectly fixed. It matters for CCTV because it means the same VBR-configured camera will naturally consume more storage during high-motion periods and less during quiet ones — exactly the behavior this concept explainer describes, made explicit as an encoder setting.
Motion-based (event-triggered) recording keeps the camera at a lower frame rate, lower quality, or not actively recording during periods with no detected motion, and switches to full frame rate/quality only when motion is detected. Because most footage in most scenes is idle time, this can substantially cut total storage consumption compared to continuous, always-on recording at a fixed rate.
By accounting for each camera's expected scene characteristics in addition to resolution, frame rate, codec, and retention period — a busy loading dock, lobby, or public corridor should be budgeted for meaningfully higher realistic bitrate than a quiet back office or storage room at the identical resolution and frame rate settings, typically using manufacturer bitrate guidance or a bandwidth/storage calculator that lets scene-type assumptions be adjusted per camera rather than applied uniformly.
Try our Physical Security Studio
More calculators, simulators, and guides for this discipline.