microSD video retention calculator: bitrate, capacity and annual write load

A 128GB label does not tell a dashcam owner when yesterday's footage will be overwritten. A 4K label does not answer it either. The recorder consumes storage at a data rate, and that rate changes with the number of streams, codec, image settings, audio and the scene in front of the lens.

The first useful measurement is therefore aggregate average bitrate. Add every stream written to the card, then include audio and other continuously stored data. Capacity can then be translated into hours. The same measurement also reveals how many gigabytes the card receives per day, which is the starting point for endurance planning.

This is a calculation and validation method, not a card-buying list. After deriving retention and write load here, use the dashcam and security-camera microSD selection guide to turn the measured workload into endurance, speed-class, temperature and host-test requirements.

The recording-time formula

Use decimal units consistently:

Recording hours = Capacity (GB) × 8,000 × (1 − reserve fraction)
                  ------------------------------------------------
                  Aggregate average bitrate (Mbit/s) × 3,600

The factor 8,000 converts one decimal gigabyte to megabits. The reserve fraction covers the space that the operating plan chooses not to consume. It may include filesystem and recorder data, index files, uncertain bitrate peaks and a buffer before the oldest required footage is overwritten.

Use actual writable bytes when the recorder reports them. Do not convert a 128GB label to approximately 119GiB and then treat 119 as decimal GB in the same formula. That would count the GB/GiB display difference twice. The distinction is explained in Why 128GB shows 119GB.

The reverse calculation sizes a card for a required retention period:

Required capacity (GB) = Aggregate bitrate (Mbit/s) × Required hours × 3,600
                         -----------------------------------------------------
                                  8,000 × (1 − reserve fraction)

These equations are planning tools. The final value should come from measured recorder output, not a guessed bitrate attached to a resolution name.

Theoretical hours by capacity and bitrate

The table below assumes continuous recording, decimal capacity, no reserve and a bitrate that already includes every recorded stream. It shows the arithmetic baseline before operational margin is applied.

A buyer should not publish this table as a product promise. A 15% planning reserve reduces each result to 85% of the value shown. Variable bitrate can move the real result in either direction.

A planning dataset with reserve and annual writes

The next table applies a stated 15% reserve and converts the same bitrate into daily and annual host writes. It is calculated data, not a measurement of a particular camera or card. Its purpose is to expose the workload before a product is selected.

Annual host writes are calculated as bitrate × 10.8 × 365 ÷ 1,000. They should not be compared directly with raw NAND program/erase cycles. The controller may write more data internally than the host sent because of garbage collection, metadata and relocation. Conversely, an endurance rating may be defined under a particular workload and temperature rather than the camera's exact behavior.

For a 256GB card, the 12 Mbit/s row writes 0.51 times the labeled capacity per day; 32 Mbit/s writes 1.35 times; 50 Mbit/s writes 2.11 times. These ratios are useful workload descriptors:

Daily card writes = Host writes per day ÷ card capacity

They are not SSD-style DWPD warranty ratings unless the card supplier explicitly defines them that way. Use them to compare candidate workloads and to set the duration of an overwrite test.

Translate speed-class markings into numerical checks

The SD Association defines V6, V10, V30, V60 and V90 as minimum sequential write-performance classes under their specified access methods [1]. The number is expressed in MB/s. Convert the aggregate video stream into the same unit before making a first comparison:

This table does not prove that every V30 card passes every workload below 30MB/s. The host must support the applicable class and bus mode, and the recorder adds file rotation, metadata and command gaps. The SD Association also notes that repeated deletion and writing can fragment available areas and affect performance; its speed-class behavior is defined around specific card/host access methods [1].

The practical test is therefore two-part. First, confirm that the card marking and host requirement match. Second, record the real aggregate stream through repeated wraparound cycles while checking timestamps, dropped frames and write errors. Headline maximum write speed is not a substitute for either step.

Event recording: sensitivity analysis instead of one duty-cycle guess

Assume an active stream of 12 Mbit/s and no idle stream. The storage result changes linearly with measured event duty cycle:

A buyer who assumes 25% activity when the installed site records 50% will overstate retention by a factor of two. Measure event duty cycle at several representative sites and keep the distribution. If a low-rate parking stream remains active, add its bitrate during the idle fraction rather than treating idle as zero.

Formatting is part of the controlled setup

The SD Association recommends its SD Memory Card Formatter because general operating-system formatters may not be optimized for SD/SDHC/SDXC/SDUC cards [5]. This does not mean formatting repairs worn NAND or certifies a failing card. It gives the qualification team a documented, repeatable filesystem starting condition.

Record formatter version, format mode, filesystem, allocation settings where exposed and the recorder's own initialization step. After preconditioning and repeated wraparound, do not reformat between every measurement unless the test plan explicitly studies fresh-state behavior. Otherwise, the procedure continually removes the fragmented, used state that the deployed recorder will actually face.

Worked example for a dual-channel dashcam

Assume a recorder writes:

• front video at an average 12 Mbit/s;
• rear video at an average 8 Mbit/s;
• audio and continuous metadata at 0.256 Mbit/s.

The aggregate average is 20.256 Mbit/s. A 256GB card has a theoretical recording time of:

256 × 8,000 ÷ 20.256 ÷ 3,600 = 28.1 hours

Applying a 15% reserve gives about 23.9 planned hours. The recorder writes approximately:

20.256 × 10.8 = 218.8GB per 24 hours

The constant 10.8 converts Mbit/s into decimal gigabytes per day. This workload writes the equivalent of roughly 0.85 times the card's labeled capacity every day. That is useful endurance input, but it is not a service-life claim.

Why resolution is not enough

Two cameras marked 4K can produce very different data volumes. Bitrate depends on resolution, frame rate, codec, compression level, GOP structure, image noise, motion, WDR, overlays and audio. A quiet daytime parking area and a rainy night road do not challenge the encoder in the same way.

Axis defines bitrate as the amount of camera-generated data processed per unit of time and notes that scene content and stream settings strongly affect it [3]. Its bitrate-control paper also distinguishes variable bitrate, maximum bitrate and average bitrate. VBR preserves quality but makes storage demand less predictable, while an aggressive maximum limit can reduce forensic detail in complex scenes [2].

Codec names are not fixed multipliers. H.265 or AV1 may reduce storage for comparable quality, but the result depends on the encoder and scene. Axis measurements across several surveillance scenes show different savings between H.264, H.265 and AV1, and the paper cautions that bitrate comparisons require comparable image quality [4].

For a procurement estimate, record at least 24 representative hours. A stronger qualification captures busy daylight, low-light noise, rain, rapid motion, parking mode and any secondary stream. Divide the total bytes written by elapsed seconds to obtain a measured average. Keep the highest sustained intervals separately for write-performance testing.

Continuous, event and parking recording

Continuous recording uses the measured aggregate average directly. Event recording needs a duty cycle:

Effective average bitrate = Active bitrate × active fraction
                          + Idle bitrate × idle fraction

An event-only camera with an 8 Mbit/s active stream and a measured 25% recording duty cycle averages 2 Mbit/s if it writes nothing while idle. A recorder that keeps a low-rate parking stream has a non-zero idle bitrate. Pre-event buffers, post-event tails and frequent false triggers can make the real duty cycle much higher than a schedule suggests.

Use measured event counts from the intended installation. A warehouse aisle, urban road and parked vehicle produce different motion patterns. One optimistic daytime sample is not enough for a retention commitment.

Recording time, write speed and endurance are different checks

Recording time depends on average data rate. Reliable capture depends on whether the card and host sustain the required writes during difficult intervals. Endurance depends on cumulative writes and the behavior of the selected flash configuration.

In the dual-channel example, 20.256 Mbit/s equals an average 2.532MB/s. That arithmetic does not mean any card rated above 2.532MB/s is suitable. The SD Association states that Speed Class, UHS Speed Class and Video Speed Class symbols represent minimum sequential write-performance classes under defined conditions [1]. The recorder's required class, host bus mode, write peaks, file rotation and fragmentation still apply.

Likewise, dividing a marketing endurance number by 218.8GB/day can create false precision. A defensible estimate requires evidence for the exact card, temperature range and workload. NAND type, controller policy, write amplification, power interruptions and firmware can change the outcome. See High-endurance vs consumer microSD for the evidence framework.

How to size a card for a retention requirement

Suppose a recorder must preserve 72 hours at a measured aggregate 16 Mbit/s with a 15% reserve:

16 × 72 × 3,600 ÷ 8,000 ÷ 0.85 = 609.9GB

The design needs at least 610GB of decimal writable capacity under those assumptions. The next commercially available capacity is useful only if the host supports it. Confirm the recorder's capacity limit, filesystem behavior and loop-recording implementation before selecting a larger card.

If the required capacity exceeds host support, the engineering choices are clear: reduce average bitrate without destroying required evidence, shorten retention, record fewer streams, use event logic with measured duty cycle, or move storage to a larger medium. Buying a faster card alone does not extend recording time.

Build an uncertainty budget instead of hiding margin

A single reserve percentage is convenient, but a production decision is stronger when the team records what the margin covers. Separate variables that consume capacity from variables that threaten capture reliability.

For example, “15% reserve” should not quietly stand for five unknowns. The report can instead state that 5% is inaccessible or recorder-managed space, 6% covers the observed day/night bitrate spread and 4% is the operational overwrite buffer. Those numbers are illustrative; each product must derive its own.

Do not add every worst case blindly. Some variables are correlated, and stacking absolute maxima can create an unrealistic design. Preserve the raw measurements, identify which conditions can occur together and show the chosen percentile or upper bound. The result is an uncertainty budget another engineer can challenge and update.

Validate the estimate with a seven-day worksheet

A 24-hour capture is the minimum useful start. A seven-day run is better for systems affected by weekday traffic, weather, parking mode or day/night schedules. Record one row per day:

Compare predicted and observed retention using a signed error:

Prediction error = (observed hours − predicted hours) ÷ predicted hours

If the model predicts 24 hours and the observed overwrite point is 21.6 hours, the error is −10%. Investigate whether bitrate, available capacity, stream count or recorder overhead was wrong before increasing the reserve. Repeating the same mismatch with more margin can hide a configuration error.

File segmentation changes recovery behavior

Changing a recorder from one-minute to five-minute files normally does not change the basic bitrate-capacity equation: the encoded payload still dominates. It can change container overhead, directory activity, index updates and the amount of footage exposed when power fails during file finalization.

Test the selected segment length at rotation boundaries. Remove power during payload writing, during close/finalization and just after the next segment opens. Verify the previous file, the in-progress file and both stream timelines. A shorter segment can reduce the maximum footage contained in one damaged file, but it also increases the frequency of metadata operations. The preferred setting is therefore a measured recovery tradeoff, not a capacity shortcut.

Qualification checklist for buyers and device teams

Record these inputs before approving a card:

Run the sample in the real host. Verify the oldest and newest playable files after the target interval, check both channels, review timestamps around file rotation and repeat after controlled power cycles. The microSD incoming-inspection checklist adds lot identity and release records for production purchases.

For a Kalstor project, send the recorder model, stream settings, target retention, operating temperature, capacity range and forecast. The proposed sample and commercial terms can then be tied to a measurable qualification plan instead of a capacity label alone.

Bottom line

Start with measured aggregate bitrate. Use it to calculate recording time and daily writes, then apply a declared reserve. Check peak write behavior separately against the host requirement, and qualify endurance with the exact card in the actual recorder. That sequence turns “How long will 128GB last?” into a calculation another engineer can reproduce.