Recording
Bitrate × active hours × retention. No resolution folklore.
Independent CCTV system planning
Turn camera bitrates into a defensible storage and network plan. The arithmetic stays visible, and the project stays in your browser.
Bitrate × active hours × retention. No resolution folklore.
See the sustained recorder traffic before it reaches the switch.
Budget PoE from maximum camera draw, then add explicit headroom.
Keep channel, drive, and reserve assumptions in the same plan.
The complete toolkit
Model mixed camera groups once and check storage, recording traffic, PoE draw, channel headroom, and switch capacity together.
02 / TB requiredEstimate the decimal terabytes needed from camera count, measured or stated bitrate, recording schedule, activity, retention, and overhead.
03 / Mb/s requiredSeparate local recording traffic from remote-viewing upload and add explicit capacity headroom.
04 / Watts requiredCheck total camera load, switch power headroom, and the per-port limit using each camera’s maximum stated draw.
05 / Usable TBCompare raw, protected, and working capacity for single-disk, RAID 1, RAID 5, RAID 6, and RAID 10 layouts.
06 / Days retainedEstimate how many hours or days fit on a camera card from usable capacity, bitrate, schedule, activity, and overhead.
The Camera Ledger rule
Inputs you can verify. Formulas you can inspect. Limits you can see.
Compression efficiency changes with motion, scene detail, lighting, firmware, and encoder settings. That is why Camera Ledger starts with bitrate rather than claiming every 4K camera consumes the same storage.
TB = cameras × Mb/s × seconds recorded ÷ 8 ÷ 1,000,000
Field notes
A bitrate-first method for sizing retention without pretending resolution alone determines storage.
Where bitrate comes from, why it moves, and how to build low/base/high scenarios.
Why codec efficiency is scene-dependent and how to verify the result before buying drives.