A printable bandwidth, storage, PoE, retention and commissioning record.
Print-ready worksheetCommercial Camera Bandwidth, Storage, PoE and Retention Calculator
turn design assumptions into a reviewable capacity estimate.
Enter the camera count, estimated average bitrate per camera, recording schedule, recording activity, target retention, available usable storage, maximum camera power, and design headroom. The calculator estimates aggregate assumed camera traffic, average recording traffic, storage needed for the target retention period, estimated retention from available storage, connected camera load, and a planned PoE budget. Validate every result against selected camera, switch, recorder, VMS, scene, codec, analytics, redundancy, and policy requirements.
Camera count, bitrate, recording behavior, retention, usable storage, and power all shape the design
SRS Networks is a nationwide IT infrastructure deployment partner headquartered in South San Francisco, California, serving multi-site enterprises across the 48 contiguous states, Alaska, and Hawaii since 1996. This page turns field-delivery requirements into a scope, comparison, and acceptance record a buyer can use.
Download the actual template
Choose the print-ready copy or complete the interactive PDF electronically. No email form or account is required.
An interactive copy for design assumptions, field measurements and signoff.
Fillable PDF worksheetPlanning inputs become field measurements before the system is accepted
The calculator exposes assumptions; commissioning replaces them with the selected platform's recorded operating evidence.
Define inputs
Camera mix, scenes, recording, retention, viewing and failure conditions
Estimate capacity
Average and peak bandwidth, usable storage, PoE and switch headroom
Measure in field
Actual bitrate, uplink, power draw, recording, failover and recovery
Accept and retain
Platform export, exception log, corrected tests and owner approval
Inputs that control the estimate
| Input | Use | Confirm before procurement |
|---|---|---|
| Camera count | Total streams and powered endpoints | Current scope plus planned growth |
| Average bitrate | Traffic and storage consumed by one recorded stream | Model, codec, resolution, frame rate, scene, lighting, and compression |
| Recording schedule | Hours per day the recording profile is active | Continuous, scheduled, event, and secondary stream behavior |
| Recording activity | Estimated share of the active schedule generating recorded data | Motion profile, event rules, pre/post buffer, and low-light behavior |
| Retention | Days footage must remain available | Security policy, legal hold, operational use, and overwrite rules |
| Camera watts | Connected powered-device load | Maximum selected-camera draw with heaters, IR, wipers, audio, or accessories |
| PoE headroom | Reserve above connected load | Switch power supply, PoE class, per-port limit, derating, and redundancy |
Estimate bandwidth, storage, retention, and PoE
Use average recorded bitrate for the selected camera and scene, not resolution alone. Results use decimal terabytes and do not reserve capacity for RAID, recorder overhead, exports, failover, free-space policy, or growth unless those reductions are already reflected in the usable-storage input.
Include every recorded camera in this design group.
Use manufacturer scenario data or a measured pilot.
Enter 24 for an always-active recording profile.
Use 100% for continuous recording; validate event assumptions.
Use the approved security and evidence-retention policy.
Enter capacity available after protection and reservations.
Include heaters, IR, audio, and powered accessories.
The responsible design must approve the reserve.
Camera count multiplied by the entered per-camera bitrate; other streams and traffic are excluded.
Aggregate assumed bitrate adjusted by the recording schedule and activity inputs.
Estimated recording data only; enter overhead and protection effects through usable capacity.
Estimated days before overwrite at the calculated average recording traffic.
Camera count multiplied by maximum watts per camera, before design headroom.
Connected load plus the entered headroom; verify ports, classes, supplies, derating, and redundancy.
Treat bitrate as a design assumption
Resolution alone does not determine bitrate. Camera model, codec, frame rate, compression, scene complexity, lighting, motion, analytics, audio, and bitrate control all matter. Use manufacturer design data or a measured pilot whenever possible.
Separate storage from usable retention
Raw drive capacity is not the same as capacity available to recordings. Account for filesystem and recorder requirements, RAID or other protection, spare capacity, event buffers, exports, failover, growth, and any secondary streams before promising retention.
Validate PoE twice
Check both the total switch budget and every port. A switch can have enough aggregate watts while one camera exceeds a port class or while simultaneous startup, heaters, illuminators, or environmental derating exhausts the real budget.
Build the acceptance record step by step
1. Establish the video profile
The estimate is only as credible as the stream and scene assumptions behind the bitrate.
Camera and scene
Record the model, sensor mode, resolution, aspect ratio, frame rate, codec, compression or quality target, bitrate-control mode, day/night behavior, motion level, scene complexity, and lighting for each camera group.
Streams
Separate recorded, live-view, analytics, mobile, and failover streams. A stream used only for live viewing can affect network capacity without contributing to the normal storage estimate.
Recording mode
Define continuous, scheduled, motion, event, alarm, and pre/post-event behavior. Apply different assumptions to different camera groups instead of averaging an interior hallway with a busy loading dock.
Pilot
For high-risk designs, collect representative day, night, motion, weather, and event bitrate from the selected camera and settings. Use that measured distribution to replace generic assumptions before storage procurement.
2. Design network capacity
Camera bitrate is only one load on the path between edge devices, switches, recorders, viewing clients, analytics, and remote sites.
Recording traffic
Sum the recorded streams expected on each uplink and recorder interface. Review normal average, configured maximum, event concurrency, and failover conditions separately.
Viewing and export
Add live multi-camera views, remote clients, investigation playback, evidence exports, health monitoring, firmware, time synchronization, and management traffic where they share the same path.
Topology
Map each camera to access switch, uplink, aggregation point, recorder, storage path, and remote connection. A portfolio-wide total cannot reveal a single oversubscribed switch or WAN circuit.
Validation
Confirm switch forwarding and uplink capacity, recorder ingest and playback limits, network interface capacity, VMS architecture, multicast or unicast behavior, quality of service decisions, and failure-state routing.
3. Convert bitrate into retention
Retention is a capacity result and a policy requirement. Keep the arithmetic and the usable-capacity assumptions visible.
Core conversion
Storage in decimal TB equals camera count multiplied by average bitrate in Mb/s, recording hours per day divided by 24, recording activity, 1,000,000 bits per megabit, 86,400 seconds per day, and retention days, then divided by 8 bits per byte and 1,000,000,000,000 bytes per TB. The calculator keeps those assumptions visible so the estimate can be reproduced.
Usable capacity
Enter capacity actually available to recordings after the recorder, filesystem, RAID or protection scheme, reserved free space, failover, exports, and other workloads are accounted for.
Policy
Define whether retention is a minimum, target, or maximum; how footage is overwritten; who can place a legal or investigation hold; and whether different camera groups have different rules.
Acceptance test
After commissioning, measure real bitrate and storage consumption across representative operating conditions, project the observed retention, and document any setting or capacity change needed to meet policy.
4. Build the PoE budget
Use the selected device's maximum demand and validate the whole delivery chain, not only nominal camera watts.
Powered-device load
Include camera, heater, illuminator, wiper, microphone, speaker, encoder, wireless bridge, or other powered accessories. Confirm whether accessories draw through the camera or a separate port.
Per-port capability
Verify the switch port and cabling can deliver the required class and power at the device under the applicable design. Aggregate budget does not override a per-port limitation.
Total budget
Sum maximum planned loads, add the approved reserve, account for simultaneous startup and environmental derating, and confirm power-supply or stack redundancy behavior during a failure.
Closeout
Deliver the port-to-camera schedule, negotiated or observed power where available, switch budget, reserve, cable test results, exceptions, UPS relationship, and final configuration record.
5. Apply platform-specific architecture
Use the generic estimate to expose assumptions, then replace it with the selected platform's current capacity, retention, bandwidth, and management data.
UniFi Protect
For UniFi Protect, select the actual console or NVR, camera-resolution mix, usable storage, protection scheme, recording mode, and retention policy. Check the current UniFi capacity calculator and supported-camera guidance, then compare the estimate with Protect Storage Manager after commissioning. UniFi Site Manager at unifi.ui.com is the authenticated operations portal; it is useful for reviewing deployed consoles and settings, but it does not replace product-specific capacity validation.
UniFi retention
Document whether Protect retains full-quality footage for the entire requirement or uses Enhanced Retention to downgrade older video. Record the high-quality period, final retention setting, archive or Case Manager requirements, drive protection, usable capacity, and the consequence of a failed drive or console.
Verkada cameras
Do not model Verkada as a conventional central-NVR system. Verkada cameras record to onboard storage, while steady metadata and thumbnails, remote live or historical viewing, cloud backup, exports, and enabled features consume uplink bandwidth. Confirm the selected model's retention option, resolution, adaptive-quality behavior, HQ bitrate, viewing concurrency, backup schedule, and data-location policy in Verkada Command and current manufacturer documentation.
Verkada acceptance
Verify that every camera records through the required offline interval, returns to normal indexing after connectivity is restored, meets the purchased retention period, and supports expected concurrent remote viewing without exhausting the site uplink. Test cloud backup, Low Bandwidth Mode, local streaming, archive workflows, permissions, and evidence export when those features are in scope.
Primary technical references
Use the current project specification, adopted code, approved design, and manufacturer instructions for the final decision. These primary references explain the testing and planning basis used in this resource.
When this is not the right approach
This calculator is an early design estimator, not a product selector or engineering approval. It does not model every codec, scene, VMS, RAID scheme, recorder limit, legal-retention rule, PoE class, cable loss, environmental derating, redundancy mode, analytics stream, or failure condition. Validate the final system with current manufacturer data and qualified design review.
Straight answers
Multiply the average recorded bitrate by active recording time, recording activity, camera count, and retention period, then convert bits to bytes and account for usable-capacity constraints. Replace planning assumptions with selected-camera design data or measured pilot results before procurement.
Put a field-executable scope in front of the crew
Email the site count, geography, schedule, and current documents. Cheryl routes the request to the right deployment lead.
Review a Camera Design