How to Size IP Camera Storage
Why surveillance storage sizing is its own discipline
Sizing storage for an IP video surveillance system is not a matter of multiplying a single headline number by the camera count. The recorded data rate of a modern network camera is the product of four interacting variables — sensor resolution, compression codec, the amount of motion in the scene, and the retention window the deployment must satisfy. Get any one of them wrong and the estimate drifts by a factor of two or more, which is the difference between a recorder that meets a 30-day retention policy and one that silently overwrites week-old evidence. This calculator models all four variables against vendor-published bitrate curves so the headline terabyte figure is defensible to a client, an insurer, or an authority having jurisdiction.
The framing for this work comes from IEC 62676, the international standard family for video surveillance systems used in security applications. Part 1 establishes the general system requirements, and Part 4 provides the application guidelines that cover planning, system architecture, and storage sizing — the engineering context this tool approximates.[2] We treat those documents as the methodology backbone: the math here is a transparent, reproducible approximation of the storage-sizing guidance, not a black box.[1]
The storage formula, variable by variable
The core relationship is straightforward once the units are pinned down. Per-camera storage in terabytes equals the camera bitrate (converted from kilobits per second to bytes per second) multiplied by the number of seconds in the retention window, multiplied by the motion ratio, and divided by one trillion bytes per decimal terabyte. Total storage is that per-camera figure multiplied by the camera count. Every quantity in that chain is a real, sourced input rather than a rule-of-thumb fudge factor.
Bitrate is the dominant term and the one most often misstated. Vendors quote it in kilobits per second at a stated frame rate — almost always 30 frames per second for the headline specification. Because eight bits make a byte and storage is sold in bytes, the calculator divides the quoted kbps by eight and multiplies by one thousand to reach bytes per second. The retention window converts to seconds by multiplying the requested days by 86,400 seconds per day. Holding everything else constant, doubling the retention days doubles the storage, and the relationship stays perfectly linear because there is no compression benefit to keeping older footage.
Decimal terabytes matter here. A storage vendor advertises a "12 TB" drive as twelve trillion bytes, not the 13.2 trillion bytes that the binary tebibyte convention would imply. This calculator uses the decimal convention (one terabyte equals 10^12 bytes) so the output maps directly onto the capacity printed on the drives a contractor actually purchases, avoiding the roughly ten-percent shortfall that the binary-versus-decimal confusion routinely introduces into hand estimates.
H.264 versus H.265: the codec that halves your bill
The single largest lever after resolution is the compression codec. H.265, also called High Efficiency Video Coding (HEVC), achieves roughly a fifty-percent reduction in bitrate compared with the older H.264 codec at an equivalent perceived image quality.[1] In the seeded vendor tables this calculator carries, every H.265 figure is approximately half its H.264 counterpart at the same resolution — a 4-megapixel Hikvision stream is modeled at 4,096 kbps under H.264 and 2,048 kbps under H.265.
That fifty-percent figure is a planning approximation, not a guarantee. Real-world savings depend on the encoder implementation, the bit-rate-control mode (constant versus variable), and scene complexity: a static corridor compresses far better than a wind-blown car park full of moving foliage. For a first-pass capacity estimate, the half-bitrate assumption is sound and conservative; for a final design the integrator should validate against a representative live stream. The practical takeaway is unambiguous — if a recorder and every camera on the project support H.265, enabling it roughly halves the storage budget for free.
Motion ratio and the retention window
Continuous recording captures every second of every day; motion-only recording writes frames solely when the camera detects a motion event. The motion ratio expresses the fraction of time the camera is actually recording, so it scales the continuous-record storage linearly. A motion ratio of 0.3 — the professional default in this tool — models a camera recording roughly thirty percent of the time and yields about a seventy-percent storage saving against a continuous baseline of 1.0. A reception desk overnight might sit near 0.1; a busy retail entrance during trading hours can approach 1.0.
The retention window is usually dictated externally rather than chosen freely. Insurance policies, client service-level agreements, and local authority-having-jurisdiction requirements commonly mandate 7 to 30 days for general commercial premises, while financial, gaming, and healthcare sites frequently require 90 days or longer. Because storage scales linearly with retention, a policy change from 30 to 90 days triples the disk requirement — a budget conversation worth having before the recorder is specified, not after it ships.
Where the vendor bitrate curves come from
This calculator seeds bitrate curves for six representative IP-camera families: Hikvision, Axis, Dahua, Bosch, Hanwha, and i-PRO.[6][7] Hikvision serves as the baseline, with H.265 scaling approximately linearly with megapixel count from 512 kbps at 1 megapixel; H.264 runs at roughly double that. Dahua tracks the Hikvision baseline closely in the seeded table, and Hanwha — represented by its Wisenet bullet line — is seeded at the same baseline, reflecting the bandwidth efficiency of its WiseStream compression.[10] Axis is modeled at about a ten-percent premium, i-PRO — the former Panasonic security division — at about a twelve-percent premium,[11] and Bosch — represented by its DINION inteox line — at about a fifteen-percent premium, reflecting their higher-bit-rate positioning for low-light and forensic-detail performance.
These figures are seed values drawn from vendor specification sheets at 30 frames per second and are flagged for periodic re-verification against current published data. When a deployment uses a vendor not in the seeded set, the soundest approach is to pick the closest modeled family and then confirm the headline result against that vendor's own bit-rate calculator before committing to a recorder. The vendor-comparison table on this page exists precisely so an engineer can size against the worst-case branch relevant to the project rather than an optimistic single-vendor figure. risertools is not affiliated with any of these manufacturers, and the curves are used solely as transparent planning inputs.