Security Camera Bitrate and Recording Storage: A Reference Guide

The short answer

Recording storage is driven almost entirely by one number: the video bitrate in megabits per second (Mbps). The conversion is fixed physics, not vendor opinion. One Mbps of continuous video writes 0.45 GB per hour, which is 10.8 GB per day (24 hours) and about 324 GB over 30 days. So the whole job is estimating each camera's bitrate, then multiplying. Typical VBR bitrates at 15-30 fps are roughly: 2MP/1080p about 2-6 Mbps on H.264 or 1-3 Mbps on H.265; 4MP about 4-8 Mbps H.264 or 2-4 Mbps H.265; and 8MP/4K about 8-16 Mbps H.264 or 4-8 Mbps H.265. H.265/HEVC delivers comparable image quality at roughly half the bitrate of H.264, which roughly doubles retention on the same drive.

To size a recorder, use: storage (GB) = bitrate (Mbps) x 0.45 x hours, or per full day, GB/day = Mbps x 10.8 (equivalently 0.0108 TB/day per Mbps). For a whole system: total GB = cameras x bitrate x 10.8 x days, then add 10-20% headroom for VBR peaks and filesystem overhead. Example: eight 4MP cameras on H.265 at 3 Mbps, recording continuously for 30 days, need 8 x 3 x 10.8 x 30 = 7,776 GB (about 7.8 TB) of usable space, so you would provision roughly 10 TB. Motion-only recording multiplies that by the scene's active duty cycle (often 10-40%), and remember drive-label terabytes (decimal) are about 9% larger than the binary space the operating system reports.

Start here: codec, bitrate, retention, then drive size

Four decisions set your storage bill, in order. First, pick a codec. H.265/HEVC (and its smart variants) achieves the same perceived quality as H.264/AVC at roughly 30-50% lower bitrate, so unless a camera or client can only decode H.264, choose H.265. This single choice roughly doubles how many days fit on a given drive. Confirm both the camera and the NVR/VMS support the same codec and profile, because a mismatch forces the recorder to transcode or the camera to fall back to H.264.

Second, set a target bitrate per camera from the ranges in the next section, matched to resolution, frame rate, and scene motion. Third, choose a retention target in days, driven by policy, insurance, or how long an incident typically takes to surface (7, 14, 30, 60, and 90 days are common). Fourth, multiply through the storage formula and add headroom.

Do not size to the camera's maximum bitrate cap. Caps exist for worst-case motion; real-world VBR averages sit well below them. Size to a realistic average, then leave 10-20% margin so VBR peaks and RAID/filesystem overhead do not fill the array early.

• Codec first: H.265 vs H.264 changes storage by ~2x for the same image quality.
• Bitrate is the master variable: 1 Mbps continuous = 0.45 GB/hour = 10.8 GB/day.
• Retention in days is a policy choice; 30 days is the common default for small business.
• Size to realistic VBR average bitrate, not the camera's max cap.
• Always add 10-20% headroom for peaks, indexing, and filesystem overhead.
• Confirm camera and recorder speak the same codec/profile to avoid transcoding.

Real bitrate ranges by resolution and codec

Resolution sets the pixel count you must encode each frame: 2MP/1080p is 1920x1080 (about 2.07 million pixels), 4MP is typically 2560x1440 (about 3.7 million), and 8MP/4K is 3840x2160 (about 8.3 million). Bitrate scales with pixel count, motion, and detail, but not perfectly linearly because compression exploits redundancy. The figures below are typical good-quality VBR averages at 15-30 fps for a moderately busy scene; a static hallway sits lower, a windblown tree line or busy parking lot sits higher.

H.264/AVC typical averages: 2MP about 2-6 Mbps (call it 4 Mbps nominal), 4MP about 4-8 Mbps (about 6 Mbps nominal), 8MP/4K about 8-16 Mbps (about 12-14 Mbps nominal). H.265/HEVC runs roughly half: 2MP about 1-3 Mbps, 4MP about 2-4 Mbps, 8MP/4K about 4-8 Mbps. These match the daily-storage figures widely published by NVR and drive vendors.

Treat these as starting points, then verify on the actual scene. The only authoritative bitrate is the one the installed camera reports on your view, at your chosen frame rate and quality, over a representative day.

• 2MP/1080p (1920x1080): H.264 ~2-6 Mbps; H.265 ~1-3 Mbps (about 22-65 GB/day H.264, 11-32 GB/day H.265).
• 4MP (2560x1440): H.264 ~4-8 Mbps; H.265 ~2-4 Mbps (about 43-86 GB/day H.264, 22-43 GB/day H.265).
• 8MP/4K (3840x2160): H.264 ~8-16 Mbps; H.265 ~4-8 Mbps (about 86-173 GB/day H.264, 43-86 GB/day H.265).
• H.265/HEVC uses roughly 30-50% less bitrate than H.264 for equivalent quality.
• Busy/high-motion scenes push toward the top of each range; static scenes toward the bottom.
• Nominal single-number planning values (H.264): 2MP=4, 4MP=6, 4K=14 Mbps; halve for H.265.

The storage math: from Mbps to terabytes

The conversion is exact. One megabit per second is 1,000,000 bits/s = 125,000 bytes/s = 0.125 MB/s. Over an hour that is 0.125 x 3600 = 450 MB, or 0.45 GB (decimal, 1 GB = 1000 MB). Over a full 24-hour day it is 10.8 GB. Restated as a constant: GB/day per Mbps = 10.8, equivalently 0.0108 TB/day per Mbps. These are the only constants you need.

Two working formulas follow. For a single camera over any number of hours: storage (GB) = bitrate (Mbps) x 0.45 x hours. For a whole system recording continuously: total storage (GB) = cameras x bitrate (Mbps) x 10.8 x days. Divide by 1000 for terabytes. If you record motion-only, multiply by the fraction of time the scene is active (the duty cycle).

A note on units: hard drives are labeled in decimal terabytes (1 TB = 1,000,000,000,000 bytes), but operating systems report binary tebibytes (TiB), which are about 9% smaller. A 10 TB drive presents roughly 9.09 TiB of usable raw space before any RAID or filesystem overhead. Plan capacity against usable space, not the label.

• Core constants: 1 Mbps = 0.45 GB/hour = 10.8 GB/day = ~324 GB/30 days = 0.0108 TB/day.
• Single camera: GB = Mbps x 0.45 x hours.
• Full system, continuous: GB = cameras x Mbps x 10.8 x days.
• Motion-only: multiply the continuous result by the active duty cycle (e.g. 0.20 for 20%).
• Convert GB to TB by dividing by 1000; add 10-20% headroom on top.
• A '10 TB' drive = ~9.09 TiB usable raw (decimal-vs-binary), before RAID/format overhead.

CBR vs VBR, frame rate, and smart codecs

CBR (constant bitrate) holds a fixed rate regardless of scene activity. Storage is perfectly predictable, but the encoder wastes bits on empty static scenes and can starve detail when a busy scene exceeds the cap. VBR (variable bitrate) spends bits on motion and detail and saves them on still scenes, giving better quality-per-bit and usually lower average storage. VBR is the default for most deployments; CBR earns its place only when a link or recorder needs a hard, predictable ceiling (fixed WAN budgets, strict per-channel limits). With VBR, always set a sensible max/cap so a single stormy, high-motion day cannot balloon the array.

Frame rate scales bitrate, but sub-linearly. Cutting 30 fps to 15 fps typically saves roughly 30-50% depending on motion, not exactly half, because inter-frame prediction already removes much redundancy between similar frames. Many surveillance scenes are fully usable at 12-15 fps.

Smart codecs (H.264+, H.265+, Smart Codec, Zipstream, SVC) add dynamic GOP length and per-region quantization: they lower bitrate hard on static regions and raise it only where something moves. On mostly-still scenes they cut another 30-50%+; on constantly busy scenes savings shrink toward the baseline codec.

• VBR: variable rate tracks scene complexity; better quality-per-bit, less predictable size. Set a max cap.
• CBR: fixed rate; predictable storage, but wastes bits on static scenes and can starve busy ones at the cap.
• Frame rate scales bitrate sub-linearly; 30->15 fps saves roughly 30-50%, not exactly half.
• Smart codecs (H.265+, Zipstream, Smart Codec) cut 30-50%+ more on static scenes only.
• Higher-motion and higher-detail scenes reduce every codec's compression advantage.
• Plan storage from average VBR bitrate; use the max cap only to bound worst-case peaks.

Motion vs continuous, and sizing a real NVR

Continuous recording writes 24 hours a day; motion-only writes only while the scene is active, so it multiplies storage by a duty cycle. A quiet back door might be active 10% of the day; a busy retail floor 30-40%. Motion recording should always include a pre-event buffer (typically 3-10 seconds) and a post-event tail, which adds a little beyond the raw active time, and it depends on reliable detection to avoid missing an event that starts before the trigger.

Worked example, continuous: eight 4MP cameras on H.265 at a 3 Mbps average, 30-day retention. Per camera per day = 3 x 10.8 = 32.4 GB. System per day = 8 x 32.4 = 259.2 GB. Over 30 days = 7,776 GB, about 7.8 TB usable. Add ~15% headroom -> about 9 TB, so provision 10 TB usable (more raw if using RAID redundancy).

Same eight cameras on H.264 at 6 Mbps would need 8 x 6 x 10.8 x 30 = 15,552 GB, about 15.6 TB usable - roughly double, which is exactly the codec penalty. At a 40% motion duty cycle, the H.265 case drops to about 3.1 TB usable.

• Motion-only storage = continuous storage x active duty cycle (commonly 0.10-0.40).
• Include a pre-event buffer (3-10 s) so the clip captures the moment before the trigger.
• Example: 8x 4MP H.265 @3 Mbps, 30 days continuous = 8x3x10.8x30 = 7,776 GB (~7.8 TB usable).
• Add ~15% headroom -> ~9 TB; provision a 10 TB usable target for VBR peaks and overhead.
• Same 8 cameras on H.264 @6 Mbps = ~15.6 TB usable (about 2x the H.265 case).
• RAID reduces usable space: RAID 5 loses one drive of capacity; RAID 6 loses two; RAID 1 halves it.

Gotchas that break storage estimates

Estimates go wrong for predictable reasons. Sizing to the camera's max bitrate cap instead of its VBR average massively over-provisions, while ignoring VBR peaks under-provisions. Infrared night mode often raises bitrate: IR-illuminated scenes carry sensor noise that compresses poorly, and low light plus moving shadows can push nighttime bitrate above daytime. Wide dynamic range, high-detail textures (gravel, foliage), and any camera-side overlays also raise the encoded rate.

Unit confusion is common. Mixing bits and bytes introduces an 8x error; mixing decimal GB/TB with binary GiB/TiB introduces about 7-9%. RAID overhead is separate again: RAID 5 sacrifices one drive of capacity, RAID 6 two, and RAID 1 halves it, so raw purchased capacity must exceed usable capacity. Drives also should not be filled to 100%; recorders need free space to index and overwrite cleanly.

Finally, retention is a floor, not a promise: if bitrate runs higher than planned, the recorder simply overwrites older footage sooner and you keep fewer days than intended. Verify the achieved retention on the installed system across a representative week, day and night, rather than trusting the spreadsheet alone. Where recording must satisfy insurance, evidentiary, or compliance retention, a professional installer can measure real per-camera bitrate on each scene, size the array with correct RAID and headroom, and confirm the days-retained figure holds under night and peak-motion conditions before you rely on it.

• Size to VBR average, not the max cap, but bound the cap so peaks can't overrun the array.
• Night/IR mode often increases bitrate: sensor noise and low light compress poorly.
• Bits vs bytes = 8x error; decimal GB vs binary GiB = ~7-9% error. Keep units consistent.
• RAID reduces usable capacity: RAID 5 = -1 drive, RAID 6 = -2 drives, RAID 1 = half.
• Don't plan to fill drives to 100%; recorders need free space to index and overwrite.
• Retention is a floor: higher-than-planned bitrate shortens the days actually kept.

Frequently asked questions