A camera's resolution does not determine recording storage. Start with the average bitrate of the stream you will actually record, camera count and recording schedule.
Formula and units
Video TB = sum(camera count * average Mbps) * hours/day * days * 0.00045
Mbps means one million bits per second; TB means one trillion bytes. This estimates encoded video only, before audio, recorder overhead and reserve space.
Eight cameras averaging 4 Mbps, recording 24 hours/day for 30 days, use 10.368 TB of video payload. A 4 TB allocation for video holds about 11.57 days with the same assumptions. These are calculations, not measured recorder results.
Mixed camera groups
Four cameras at 4 Mbps plus two at 2 Mbps total 20 Mbps. At 24 hours/day for 14 days, the payload is 3.024 TB. Calculate different recording schedules separately. Use representative busy and nighttime measurements when available.
Adding 20% to that payload gives 3.6288 TB. Reserving 20% of total capacity instead requires 3.024 / 0.8 = 3.78 TB. Neither percentage is a universal manufacturer requirement.
Check assumptions and verify retention
A configured bitrate ceiling is different from an average. Event recording depends on activity and pre/post-event buffers; it does not guarantee a fixed saving. Do not apply another codec discount to a bitrate that already reflects compression.
Check supported drive models, bays, per-drive capacity, redundancy and actual space available for video. Review every channel, playback and export. A one-day sample can refine a forecast; only checking the required recording window after enough time has elapsed verifies retention.
Axis explains bitrate-control methods; its available controls depend on the model.
QuarkView maintains a storage calculator and worksheet for comparing these assumptions. We are the team behind the resource. It provides planning estimates, not a recorder-capacity or retention guarantee.
Top comments (0)