Recorder Storage Math: Bitrate, Days and Cameras

Why this matters

Customers ask for retention in days ("I want a month"), recorders are sold in terabytes, and cameras stream in megabits per second. The conversion between those three is simple arithmetic, and when nobody does it the customer finds out the hard way: they go looking for footage from three weeks ago and the recorder overwrote it two weeks back. Retention is also the one camera-system promise that cannot be checked on install day, because a recorder with an empty drive will happily say it is recording. It has to be calculated before the sale and verified once the drive has filled.

The calculation

ONE CAMERA, ONE DAY
  4 megabits per second (Mbps), constant bitrate
  x 86,400 seconds per day
  = 345,600 megabits per day
  / 8 bits per byte
  = 43,200 megabytes = 43.2 GB per camera per day

EIGHT CAMERAS, 30 DAYS
  43.2 GB x 8 cameras   = 345.6 GB per day
  345.6 GB x 30 days    = 10,368 GB = about 10.4 TB

CHECK, RUN BACKWARDS
  10,368 GB / 30 days / 8 cameras = 43.2 GB
  43,200 MB x 8 bits = 345,600 megabits
  345,600 / 86,400 seconds = 4.0 Mbps

Watch the bits and bytes. Camera bitrates are in bits (small b, Mbps). Storage is in bytes (big B, GB and TB). There are 8 bits in a byte, so a 4 Mbps stream fills half a megabyte per second. Dropping the divide-by-8 is the single most common mistake in this calculation, and it makes the answer eight times too big, which is the kind of error that gets caught. Forgetting it in the other direction, when someone reads "4 MB" off a spec sheet that meant megabits, makes the answer eight times too small, which does not get caught until the footage is gone.

Watch the two kinds of terabyte. Drive makers sell in decimal terabytes (1 TB is 1,000,000,000,000 bytes). Many recorders and computers display in binary units, where one "TB" on screen is about 1.1 decimal TB. The 10,368 GB above is about 9.4 of those binary units, and a recorder showing "9.4 TB" for it is not short-changing anyone. Usable space after the recorder formats the drive and reserves some for its own use is a little less again. The figure to plan against is the usable capacity the recorder reports, converted to the same units as your daily total.

What moves the bitrate

The 4 Mbps in the example is a setting, and real streams depend on more than the setting.

Resolution and frame rate. More pixels and more frames per second take more bits for the same quality. A 2560 pixel wide stream at 15 frames per second is a common residential setting; going to 30 frames per second costs bitrate and rarely helps identify anyone, because a face is legible in one sharp frame.

Codec. H.265 (HEVC) typically needs substantially less bitrate than H.264 for similar quality, often cited as up to about half. Many recorders also offer the maker's own "smart" variants that drop bitrate further on static scenes. The saving is real but scene-dependent, and every camera and the recorder must support the codec.

Constant versus variable bitrate. A constant bitrate (CBR) stream uses its set rate every second, which makes storage predictable. A variable bitrate (VBR) stream uses less on a still scene and more on a busy one, up to a cap you set. For a guaranteed retention figure, size against the VBR cap, not the average you saw on a quiet afternoon.

The scene. Moving leaves, rain, snow, traffic, and above all night. Under infrared a sensor produces noise across the whole image, and the encoder treats that noise as detail it has to send. A VBR camera that runs well under its cap at noon can run at its cap all night. A storage estimate built from a daytime test misses half of every day.

Recording mode. Continuous recording fills the drive at the full rate around the clock. Motion or event recording records only when something triggers, plus a pre-event and post-event buffer. On a quiet back yard that might be a small fraction of the day; on a camera facing a street or a tree it can be most of it. Motion recording makes retention longer and less predictable, and an event the camera's detection missed is not recorded at all.

Worked example: the customer who wanted a month

The ask. Eight cameras, continuous recording, 30 days of retention, faces identifiable at the front door and driveway. The cameras are set to 2560 pixels wide, 15 frames per second, H.265, CBR at 4 Mbps; the dealer chose that rate as the lowest at which faces at the design distances stayed sharp at night on a test clip (see related: Camera Field of View and Pixels per Foot).

The quoted recorder. The original quote carried two 4 TB drives, 8 TB in all.

Run it. From the box above, eight cameras at 4 Mbps need 345.6 GB per day. 8,000 GB / 345.6 GB per day = about 23.1 days. The quote promised 30. It falls short by about 7 days.

The options, each run through the same numbers:

• Lower the bitrate to 3 Mbps. Per camera: 3 x 86,400 / 8 = 32,400 MB = 32.4 GB per day. Eight cameras: 259.2 GB per day. 8,000 / 259.2 = about 30.9 days. On paper it just makes it, with under a day of margin, and it undoes the reason 4 Mbps was chosen. Rejected: the customer's priority was faces.
• Switch to motion recording. Possibly far longer retention, but nobody can promise a number until it has run, and a missed trigger is missing footage. Rejected for the front door and driveway; kept as a later option for the two back-yard cameras.
• Add a third 4 TB drive, 12 TB in all. 12,000 / 345.6 = about 34.7 days on paper. Chosen.

What the recorder actually reported. With three drives installed and formatted, the recorder reported 11,880 GB usable, not 12,000. On paper that is 11,880 / 345.6 = about 34.4 days.

Verifying retention instead of assuming it

Two checks, at two points in time. Both are done on the recorder.

The fill-rate check, a few days in. Two days after go-live, the recorder showed 710 GB used. 710 / 2 = 355 GB per day, not the 345.6 the math predicted; recorders store some overhead with the video, and these cameras ran right at their rate all night. Using the measured rate: 11,880 / 355 = about 33.5 days. Still over 30, with a margin of about 3.5 days, or roughly 12 percent of the promised month. That number, not the quote, goes in the handover. See related: How to Set Up a Network Video Recorder and Confirm Retention.

The overwrite check, once the drive is full. The fill-rate check is a prediction. The proof comes after the recorder starts overwriting: on a visit or a remote session a little past day 34, open playback and find the oldest recording on each camera. The date of the oldest recording, counted back from today, is the actual retention. If it is 30 days or more on every camera, the promise holds. If one camera shows fewer days, look for a camera running a higher rate than the rest or a camera whose recording schedule was set differently.

What would have happened without either check. The original 8 TB recorder would have run a little over 22 days at the measured 355 GB per day (8,000 / 355 = about 22.5), and the first anyone would have known was the day the customer needed footage from day 25. That is exactly the call covered in The Recorder That Only Kept Four Days, with smaller numbers.

How much margin to promise. A sensible shop default is to quote a retention figure only when the measured fill rate supports it with at least 10 percent to spare, because the rate drifts upward with weather, seasons and added cameras. This job's 33.5 days against 30 promised is about 12 percent over, so it clears that default; the 30.9 days the 3 Mbps option offered on paper would have been 3 percent over before anything was measured, and would not have.

Estimating motion recording from a measurement, not a guess

Six weeks later the customer asks to move the two back-yard cameras to motion recording to stretch retention. There is no formula for how often a back yard moves, so the dealer measures: the two cameras are switched to motion recording for a week, and the recorder's per-camera usage shows each one used about 9 GB a day, against the 355 / 8 = about 44.4 GB a day each camera averages on continuous recording. That is roughly a fifth of the continuous figure.

New daily total: six continuous cameras at 44.4 GB is about 266.4 GB, plus two motion cameras at 9 GB is 18 GB, for about 284.4 GB a day. 11,880 / 284.4 = about 41.8 days.

Two cautions travel with that figure. It was measured in one dry week; the same yard in autumn, with leaves blowing and earlier darkness, triggers more, so the dealer re-checks the per-camera usage on the next visit before telling the customer "about six weeks." And while most recorders overwrite the oldest footage first across the shared drive, so every camera still keeps about the same number of days, anything those two cameras did not detect was never recorded at all.

Where the plan breaks after handover

• A camera gets added. Nine cameras at 355 / 8 = about 44.4 GB each per day is about 399.4 GB per day, and the same 11,880 GB now holds about 29.7 days. Adding one camera breaks a month that had a 12 percent margin. Retention is recalculated every time the camera count or a stream setting changes.
• Someone raises a setting. A customer who turns up the frame rate or switches a camera from H.265 to H.264 to make an app work changes the rate for that camera and shortens everyone's retention, because cameras share the drive.
• A drive fails. Recorders without redundancy lose the footage on a failed drive and the capacity with it. Retention drops by that drive's share until it is replaced. A recorder health check belongs in any service visit.

References

• Camera and recorder maker documentation: supported codecs, bitrate settings, usable capacity
• See related: How to Set Up a Network Video Recorder and Confirm Retention
• See related: Camera Field of View and Pixels per Foot
• See related: The Recorder That Only Kept Four Days