The arithmetic, in one line
Storage for video is a single multiplication and everything else is bookkeeping. Bitrate divided by eight gives bytes per second. Multiply by the number of seconds recorded, multiply by the number of cameras, and that is the footage. A camera at 4096 kbps is 512,000 bytes per second, which over a full day is about 44.2 gigabytes. Four of those cameras running continuously for fourteen days is roughly 2.48 terabytes, and with ten percent overhead the drive has to be about 2.75 terabytes.
Frame rate does not enter that line at all, which surprises people. Frame rate affects the bitrate, and the bitrate is what you record. It affects it much less than proportionally, because a compressed video stream mostly encodes what changed between frames rather than each frame from scratch. Halving the frame rate on a scene where nothing moves saves almost nothing; halving it on a busy street saves a fair amount. The preset in this calculator models that as a partial scaling rather than a direct one, which is closer to reality than either extreme.
Where the estimate goes wrong
Almost every camera records at a variable bitrate, and the figure in its settings is a ceiling rather than an average. On a still scene the stream sits far below the cap. On a scene with rain, moving foliage, headlights sweeping across a wall, or infrared illumination attracting insects, it pins to the cap and stays there. That is why two identical cameras on the same recorder can differ by a factor of three in what they write.
| Scene | Effect on real bitrate | Why |
|---|---|---|
| Empty corridor, static | Far below the cap | Almost nothing changes between frames |
| Garden with trees | Near the cap in any wind | Every leaf is fine detail in motion |
| Rain or snow | At the cap | Random motion across the whole frame defeats prediction |
| Night, infrared on | Above the daytime figure | Sensor noise looks like motion to the encoder |
| Street with traffic | At the cap in daylight hours | Large moving objects and changing exposure |
The practical response is to record for a week at your intended settings, look at what the recorder actually wrote, and size from that. Nothing on this page beats a measurement of your own scene.
Motion-only recording, and what it quietly costs
Recording only when something moves is the largest single saving available, often a factor of five or more. It is also the setting most likely to disappoint after an incident, for two reasons that are worth separating.
The first is that detection has a latency. By the time motion is confirmed and recording starts, the interesting second has passed. Pre-roll buffering fixes this and every recorder worth using has it, but it also means each event is longer than the motion that triggered it, which is why the calculator asks for the event count separately from the motion percentage. Three hundred events a day with ten seconds either side is nearly two extra hours of recording.
The second is that detection fails in exactly the conditions where you most want footage. Heavy rain, a scene full of moving branches, or fog will either flood you with triggers or, once you turn the sensitivity down to cope, quietly stop triggering on the thing that matters. Continuous recording has none of that subtlety. A defensible compromise on a mixed system is continuous on the two or three cameras covering the ways in, motion-only on the rest.
Terabytes, tebibytes, and why the drive looks small
Drives are sold in decimal terabytes, a trillion bytes each. Operating systems mostly count in binary, where a terabyte is 1,099,511,627,776 bytes, and then display the result with the same three letters. That is the whole of the missing ten percent that people report on new drives. Neither convention is wrong and neither is deceptive; they are two units with one name. This calculator prints both figures so the box and the recorder can be reconciled. On top of that, formatting takes a slice, the recorder holds a reserve so that a full disk does not stall writes, and any redundancy scheme takes its own cut before you see a byte. The storage array capacity calculator handles that last part if the recorder is a multi-drive array rather than a single disk, the pixel density calculator is where the resolution choice driving all of this gets made, the camera bandwidth calculator takes the same bitrates and asks whether the network can carry them, and the video file size calculator does the same conversion for one exported clip rather than a system running all year.
Retention as a decision, not a maximum
The instinct is to keep as much as the drive will hold. It is worth pausing on that. Footage that exists can be lost, can be demanded, and can be read by anyone who gets into the recorder — and recorders exposed to the internet with the credentials they shipped with are the ordinary route by which home footage ends up in places nobody intended. Longer retention also means more of other people going about their day is stored on your drive, which is the part of this that has legal weight in some places and none in others. Whether there is a rule about how long you may keep it, or an obligation attached to keeping it, depends on where you are, and it is a question for local guidance rather than for a calculator.
The setting worth arguing with is the one the recorder ships with, which is to fill the disk and then overwrite the oldest footage forever. That is a reasonable behaviour and it is not a decision anybody made. Deciding the retention period deliberately, and buying the drive that matches it, is a different act from letting the hardware pick.
Questions people ask
How much storage do I need for 6 cameras for 30 days?
It depends almost entirely on bitrate, so the honest answer is a range with a method attached. Six 1080p cameras at 4 Mbps recording continuously write about 265 gigabytes a day, which is roughly 8 terabytes over thirty days before overhead — call it a 10 terabyte drive. Move those cameras to H.265 at 15 frames per second and the same thirty days lands closer to 3.5 terabytes. Switch to motion-only on a quiet scene and it can fall under a terabyte. The two settings that matter most are the codec and the recording duty, and both are usually adjustable on cameras you already own.
Does lowering the frame rate save much storage?
Less than you would expect, and it depends on the scene. Modern codecs mostly encode differences between frames, so on a still scene the extra frames cost very little and removing them saves very little. On a busy scene with a lot of motion the saving is real but still well short of proportional. Halving frame rate typically saves somewhere in the region of a quarter of the bitrate rather than half. What you give up is motion smoothness, which matters when you are trying to follow a fast movement or read something in a single frame. Switching codec from H.264 to H.265 usually saves more than any frame rate change, for no loss of information at all.
Should I record continuously or only on motion?
Continuously on the cameras covering the ways in, motion-only on the rest, if you have to choose. Motion recording saves a great deal of space and fails in a specific way: it misses the seconds before the trigger unless pre-roll is enabled, its sensitivity has to be tuned down in weather that produces constant false triggers, and once it is tuned down it can miss real events. Continuous recording has no such subtlety, which is exactly its value. If storage forces motion-only everywhere, make sure pre-roll is on, review the event log after a week of real weather, and understand what the setting is trading away.
Why does my 8 TB drive only show about 7.3 TB?
Because the drive is sold in decimal terabytes and the computer counts in binary ones, and both call the result TB. Eight trillion bytes divided by 1,099,511,627,776 is 7.28, which is the number your recorder shows. Nothing has been lost and nothing has been misrepresented. Formatting and the recorder reserve then take a further slice on top, which is what the overhead percentage in this calculator covers. The calculator prints the figure both ways so that the number on the box and the number on the screen stop looking like a contradiction.
Do I need surveillance-rated drives?
It is a duty-cycle question rather than a capacity one. A recorder writing several continuous streams around the clock is a very different workload from a desktop drive that idles most of the day, and drives sold for surveillance or for network storage are specified for that sustained write pattern and for running in a warm box alongside several others. Ordinary desktop drives do work and plenty of people run them; they are not specified for it, and they tend to fail sooner. Given that the whole point of the recorder is to have the footage when you need it, the reliability side is worth more attention than the price per terabyte.