Media bandwidth and storage

Calculate network capacity and recording capacity separately. State bitrate, retention and overhead assumptions so the result can be reviewed.

Overview#

Capacity is a workload model, not a camera count lookup. Measure representative streams and failure modes, preserve units, and keep payload, network, usable storage, raw media, and retained evidence as distinct quantities.

The worked scenario is a synthetic unit checking worksheet, not a recommendation, field measurement, or product capacity result.

Unit discipline#

Network tools often report bit/s while storage products report decimal bytes and operating systems may display binary units. Always write the unit, prefix basis, and whether a value is payload, wire, usable, or raw.

Core model#

For stream i:

mean_payload_bps_i = mean_video_bps_i + mean_audio_bps_i + mean_metadata_bps_i

retained_payload_bytes =
  sum(mean_payload_bps_i × recorded_seconds_per_day_i × retention_days_i) / 8

planned_logical_bytes =
  retained_payload_bytes × container_index_filesystem_factor

required_raw_bytes =
  planned_logical_bytes × storage_protection_factor / target_fill_fraction

The factors aren't universal constants:

• container_index_filesystem_factor must come from measurement or documented architecture and can include container, index, thumbnail, database, journal, filesystem, and metadata effects;
• storage_protection_factor must be calculated for the exact mirror/replica/erasure/parity layout, drive count/capacity, hot spares, and failure policy;
• target_fill_fraction is a design selected operating limit below physical fullness, not a standards value.

Don't multiply an already vendor reported “usable after protection” capacity by a protection factor again.

Network model#

Don't apply one fixed percentage for network overhead across all packet sizes and transports. Measure actual wire behaviour. Average bitrate sizes retention; peak and burst behaviour sizes interfaces, buffers, switching, uplinks, and recorder ingest.

Workload variables#

For each stream or policy class, record:

Use codecs and streaming, recording, storage, and retention, and the offline defensive capacity lab.

Synthetic worked worksheet#

The worksheet is conceptual arithmetic using synthetic assumptions.

Assume solely for demonstrating units:

• 48 continuously recorded streams;
• 4 Mbit/s measured mean payload per stream;
• 30 days retention;
• an assumed logical overhead factor of 1.12;
• an assumed target fill fraction of 0.75;
• calculate one logical copy first; don't assume a protection factor.

per stream per day
= 4,000,000 bit/s × 86,400 s / 8
= 43,200,000,000 B
= 43.2 GB (decimal)

48 streams × 30 days
= 43.2 GB × 48 × 30
= 62,208 GB
= 62.208 TB retained payload

logical data including the synthetic 1.12 factor
= 62.208 TB × 1.12
= 69.67296 TB

raw capacity before any protection-layout factor,
at the synthetic 0.75 target fill
= 69.67296 TB / 0.75
= 92.89728 TB

This result is deliberately incomplete. If the exact design needs mirroring, parity, erasure coding, replicas, hot spares, or cloud copies, calculate the real physical/raw effect from that design. Don't simply double it unless the storage architecture truly stores two full physical copies and no other effects apply.

The corresponding assumed mean video payload is 48 × 4 Mbit/s = 192 Mbit/s. That isn't peak wire rate. A synthetic peak multiplier would be only a scenario input, never a codec fact.

Retention isn't only capacity#

• Define whether “30 days” means 30 × 24 hours, calendar day boundaries, or local time policy through daylight saving transitions.
• Treat legal hold, incident bookmark, export, and evidence copy as separate retention states.
• Define deletion authority, propagation, tombstone/audit evidence, failed deletion, backup/replica behaviour, and clock source.
• Record gaps explicitly; don't extend an older image and call it continuous retention.
• Preserve source stream/configuration changes so bitrate shifts and evidence interpretation are explainable.
• Separate storage occupancy from searchable/indexed/decodable evidence availability.

Jurisdiction, regulator, contract, labor/privacy, evidence, and litigation requirements require qualified review. This page provides no universal retention period.

Failure and recovery capacity#

Normal steady state utilization can conceal failure bottlenecks. Model at least:

• one recorder/node/link/PSU/drive/failure domain unavailable;
• rebuild or re protection reads/writes while recording continues;
• simultaneous device restart and keyframe burst after power/network restoration;
• edge recording backlog upload plus live ingest;
• export/playback during an incident;
• replication site or cloud path unavailable and later catching up;
• metadata/index rebuild and database recovery;
• depleted free space, retention deletion lag, and backpressure behaviour.

Availability claims need measured sustained performance at the intended fill level and failure state, not disk/interface headline throughput.

Acceptance worksheet#

• Decimal/binary and bit/byte units explicit
• Every stream class has measured mean, peak window, and variability evidence
• Video, audio, metadata, container/index/filesystem effects separated
• Continuous/event/schedule/pre/post recording seconds defined
• Logical, usable, raw, protected, spare, reserve, and target fill capacities separated
• Live/playback/export/analytics/replication/rebuild concurrency modeled
• Day/night, motion, weather, firmware, codec, and configuration changes sampled
• Network payload, wire rate, packet rate, loss/retransmission, and uplink oversubscription supported by environment evidence
• Failure, restoration surge, edge backlog, and degraded protection modeled
• Retention/legal hold/deletion/privacy rules approved by qualified owners
• Result recorded as assumption, calculation, vendor claim, or environment measurement, not mixed

Sources#

• BIPM SI, The International System of Units (SI Brochure), 9th edition, BIPM, current online edition accessed 25 August 2026.
• IEC INFO, IEC 80000-13:2025, quantities and units for information science and technology, IEC, 2025.
• RTP, RFC 3550: RTP, IETF, July 2003.
• H264 RTP, RFC 6184: RTP Payload Format for H.264 Video, IETF, May 2011.
• H265 RTP, RFC 7798: RTP Payload Format for HEVC, IETF, March 2016.
• AV1 RTP, RTP Payload Format for AV1 v1.0.0, Alliance for Open Media, final deliverable, 15 December 2024.

Section overview · Wiki home