CCTV Storage Calculator

How the CCTV Storage Calculator Works

The CCTV Storage Calculator estimates how much recording storage a camera system needs from:

• number of cameras;
• per-camera bitrate or camera settings;
• recording hours per day;
• active-recording percentage;
• audio bitrate;
• retention period;
• system-overhead allowance.

It can also compare the required storage with usable NVR, server, or storage-pool capacity.

The calculator supports two bitrate methods:

Use known-bitrate mode whenever a representative real bitrate is available because it requires fewer assumptions.

Example: Eight 2 Mbps Cameras for 30 Days

Suppose:

1. Calculate Effective Recording Time

Continuous recording means:

24 hr/day × 100% = 24 effective recording hr/day

2. Calculate One Camera’s Daily Payload

A 2 Mbps stream contains:

2,000,000 bits/second

Over 24 hours:

2,000,000 × 86,400 ÷ 8

= 21,600,000,000 bytes

Using decimal storage units:

= 21.60 GB/day

before system overhead.

3. Apply System Overhead

With a 5% allowance:

21.60 × 1.05 = 22.68 GB/day

for one camera.

4. Apply Camera Count

For eight cameras:

22.68 × 8 = 181.44 GB/day

5. Apply Retention

For 30 days:

181.44 × 30 = 5,443.20 GB

Equivalent to:

• 5.44 TB
• approximately 4.95 TiB

The main outputs are:

The 16 Mbps figure is the combined bitrate while all eight cameras are actively saving footage. Recording schedule and activity determine how long that active bitrate contributes to storage.

Set Continuous, Scheduled, or Motion Recording

Storage depends on both:

• how long recording is enabled;
• how much of that period becomes saved footage.

The calculator uses:

Effective recording hours/day = Scheduled hours × Active recording % ÷ 100

Continuous Recording

For full-day recording:

• schedule: 24 hr/day
• activity: 100%

Result:

24 effective hr/day

Scheduled Recording

If recording is enabled for 12 hours each day:

• schedule: 12 hr/day
• activity: 100%

Result:

12 effective hr/day

Motion or Event Recording

If detection is enabled for 24 hours but saved footage occupies an estimated 20% of that time:

24 × 20% = 4.8 effective hr/day

For a 10-hour schedule with 30% saved activity:

10 × 30% = 3 effective hr/day

The activity percentage changes the amount of recorded time. It does not reduce the bitrate of a stream while that stream is actively being recorded.

For example, a camera recording at 2 Mbps with 20% activity is modeled as:

2 Mbps for 20% of the scheduled period

not as a continuous:

0.4 Mbps stream

If your bitrate is already a full-day average that includes inactive periods, use that averaged bitrate with 100% activity or derive an active-recording bitrate before applying a lower activity percentage.

Account for Motion-Recording Buffers

Motion-based recording may save footage before and after the detected event.

Real saved duration can include:

• pre-event footage;
• post-event footage;
• retrigger extensions;
• repeated events;
• continuous-recording fallback.

The calculator does not provide separate fields for these periods.

Include their expected effect in the active-recording percentage.

For example, a quiet indoor camera can have a much lower saved-time percentage than a camera facing traffic even when both use identical video settings.

Calculate Storage From a Known Bitrate

Known-bitrate mode is appropriate when you have a meaningful average bitrate from sources such as:

• measured recording data;
• configured CBR bitrate;
• ABR target;
• representative manufacturer information;
• recorder or stream statistics.

The full retention calculation is:

Retention bytes = [(Video Mbps + Audio kbps ÷ 1,000) × 1,000,000 × Effective hours/day × 3,600 ÷ 8] × (1 + Overhead % ÷ 100) × Cameras × Retention days

The bitrate entered should represent the archived video streams for one camera.

For independent surveillance-system planning, the official AXIS Site Designer can also estimate bandwidth and storage from system-design assumptions.

Include Every Archived Stream

Suppose one camera stores:

Combined archived bitrate:

3 + 0.5 = 3.5 Mbps

Enter:

3.5 Mbps per camera

Camera count is applied separately, so do not multiply 3.5 Mbps by the number of cameras before entering it.

A substream used only for live preview or mobile viewing should not be included when it is not archived.

Use a Representative Average Bitrate

Variable-bitrate video does not necessarily remain at its configured maximum.

Average bitrate can vary with:

• motion;
• image detail;
• lighting;
• low-light noise;
• encoder settings;
• keyframe behavior.

A measurement covering representative daytime, nighttime, quiet, and active conditions is more useful than a short unusually static sample.

Using a maximum bitrate as though it were sustained continuously can overestimate storage.

Bitrate Units

Known bitrate can be entered in:

• kbps;
• Mbps;
• Gbps.

The calculator uses decimal networking conversions:

1 Mbps = 1,000 kbps

1 Gbps = 1,000 Mbps

For example:

2,500 kbps = 2.5 Mbps

Bitrate is measured in bits per second, while storage is measured in bytes:

8 bits = 1 byte

Estimate Bitrate From Camera Settings

When no representative recorded bitrate is available, camera-setting mode creates a planning estimate from:

• resolution;
• frame rate;
• codec reference;
• scene factor.

Its reference point is:

• 1920 × 1080
• 15 fps

The built-in codec reference values are:

The estimate is:

Estimated bitrate = Codec reference × Pixel factor × Frame-rate factor × Scene factor

These values are calculator planning assumptions rather than guaranteed rates for any specific camera. Actual bitrate still depends on the camera, encoder configuration, image content, lighting, and other conditions.

Resolution Factor

Resolution is adjusted from the 1080p reference using:

Pixel factor = (Width × Height) ÷ (1920 × 1080)

Built-in presets include:

Megapixel labels are approximate.

Use custom width and height when the actual recorded dimensions are known.

Frame-Rate Factor

The reference frame rate is 15 fps:

Frame-rate factor = Selected fps ÷ 15

This factor is part of the calculator’s estimation model. It should not be interpreted as a claim that every real encoder changes bitrate in exact linear proportion to frame rate.

Scene Factor

The calculator provides three scene assumptions:

A lower estimate can represent relatively static, clean footage.

A higher estimate can represent greater bitrate demand from:

• motion;
• fine detail;
• changing scenes;
• low-light noise.

The calculator does not analyze the footage itself.

How Codec Choice Affects the Estimate

Codec selection changes the reference bitrate used by camera-setting mode.

The key rule is:

Storage follows the bitrate actually written.

If an H.264 stream and an H.265 stream both average:

2 Mbps

they produce the same video payload over the same recording duration.

H.265 reduces the calculated storage only when it produces a lower average bitrate in the selected scenario.

The Smart H.265 option is a generic planning reference rather than a model of one manufacturer’s proprietary implementation.

Camera-Setting Mode Represents One Video Stream per Camera

Camera-setting mode estimates one archived video stream for each camera.

If the recorder stores multiple video profiles per camera, such as:

• a main stream;
• a recorded substream;
• a secondary archival profile;

combine their representative average bitrates and use known-bitrate mode.

Add Per-Camera Audio

When audio recording is enabled, the selected audio bitrate is added to each camera.

Suppose:

• video: 2 Mbps
• audio: 64 kbps

Convert audio:

64 kbps = 0.064 Mbps

Combined per-camera bitrate:

2 + 0.064 = 2.064 Mbps

If only some cameras store audio, calculate audio-enabled and silent cameras as separate groups.

Apply a System-Overhead Allowance

Recorded video and audio are not always the only data stored in the recording pool.

The optional overhead percentage can represent scalable storage associated with items such as:

• indexes;
• timestamps;
• recorder databases;
• file structures;
• metadata.

Use:

Adjusted storage = Payload storage × (1 + Overhead % ÷ 100)

At 5%:

Adjusted storage = Payload × 1.05

The percentage is an editable planning allowance rather than a fixed overhead claim for every recorder.

Keep Overhead Separate From Fixed Storage Losses

System overhead and usable recorder capacity represent different parts of the storage plan.

Suppose installed drives lose capacity because of:

• RAID parity;
• mirroring;
• hot spares;
• reserved recorder partitions.

Account for those fixed layout effects before entering the recording-pool capacity.

Then use the overhead percentage only for scalable data stored alongside the footage.

This avoids counting the same lost capacity twice.

The calculator itself does not calculate RAID capacity.

Compare Required Storage With Recorder Capacity

Capacity comparison can estimate:

• capacity remaining after a free-space reserve;
• percentage of usable capacity consumed;
• retention days supported;
• complete cameras supported for the selected retention.

Capacity can be entered in:

• GB;
• TB;
• GiB;
• TiB.

Use the recording-pool capacity available after any RAID, mirroring, hot-spare, or fixed-partition effects that you want excluded.

The calculator’s optional free-space reserve is then applied to that entered capacity.

Example: Compare the 30-Day Plan With an 8 TB Recording Pool

The eight-camera plan requires:

5,443.20 GB

Suppose:

• recording pool: 8 TB
• reserved free space: 10%

Usable capacity:

8 × (1 − 0.10) = 7.20 TB

or:

7,200 GB

Capacity Used

5,443.20 ÷ 7,200 × 100

= 75.60%

So the 30-day plan uses approximately:

75.60% of usable capacity

Retention Supported

Daily storage is:

181.44 GB

Therefore:

7,200 ÷ 181.44

≈ 39.68 days

The entered capacity supports approximately:

39.68 days

under the same camera, bitrate, recording, audio, and overhead assumptions.

Complete Cameras Supported

One camera requires:

22.68 × 30

= 680.40 GB

for 30 days.

With 7,200 GB available:

7,200 ÷ 680.40

≈ 10.58 cameras

Only complete cameras that satisfy the full retention period count, so the result is:

10 complete cameras

Understand TB and TiB

Decimal and binary storage units represent the same bytes differently.

Decimal:

1 TB = 1,000,000,000,000 bytes

Binary:

1 TiB = 1,099,511,627,776 bytes

That is why the example result can be shown as:

5.44 TB ≈ 4.95 TiB

The difference is caused by unit definitions, not missing footage or added overhead.

Use the same unit system when comparing calculated storage with recorder or drive capacity.

Split Mixed Camera Systems Into Groups

One calculation assumes that the selected cameras share the same main storage settings.

Use separate calculations when camera groups differ materially in:

• bitrate;
• schedule;
• activity;
• audio recording;
• retention;
• number of archived streams.

For example, a system containing:

• 6 continuously recorded cameras at 4 Mbps;
• 10 motion-recorded cameras at 2 Mbps;
• 4 cameras with audio;

should not automatically be compressed into one artificial average profile.

Calculate each relevant group separately and add the resulting storage totals.

For a simpler bitrate-and-duration calculation outside multi-camera surveillance retention planning, use the Video Recording Storage Calculator.

Software Input Limits

These are calculator validation limits, not recommended CCTV settings.

Calculation Boundaries

The CCTV Storage Calculator estimates storage from the assumptions entered.

It does not:

• inspect real recorded footage;
• predict exact future variable bitrate;
• measure motion frequency at the installation;
• verify camera or NVR compatibility;
• calculate RAID or mirroring layouts;
• detect existing footage on the recorder;
• detect failed or unavailable drives;
• model recorder deletion policies.

Actual retention can differ when real operating conditions differ from the values entered.

For the most reliable planning result, use representative recorded bitrate, realistic recording activity, and the usable storage capacity actually available to the recorder.

Calculation Method

Effective recording time:

Effective hours/day = Scheduled hours × Active recording % ÷ 100

Per-camera active bitrate:

Camera bitrate = Video bitrate + Audio bitrate

Recorded payload:

Bytes = Bitrate × Recording seconds ÷ 8

After system overhead:

Adjusted storage = Payload × (1 + Overhead % ÷ 100)

For all cameras:

System storage = Adjusted per-camera storage × Camera count

For the selected retention:

Retention storage = Daily system storage × Retention days

For capacity comparison:

Usable capacity = Entered recording pool × (1 − Reserved free-space % ÷ 100)

Retention supported = Usable capacity ÷ Daily system storage

Complete cameras supported = Floor(Usable capacity ÷ Per-camera storage for selected retention)

The calculator performs these calculations from the underlying unrounded values. Display precision changes only how the resulting values are shown.