All tools

Media Storage Estimator

Plan storage for multi-camera shoots by estimating camera originals, proxies, safety margin, and total project footprint across codecs, resolutions, frame rates, durations, and overhead.

Why this tool is useful

Storage gets committed before anyone knows what the shoot will actually produce. Cards get rented, shuttle drives get bought, and a cloud project gets provisioned days before the first frame is recorded. Guess low and the DIT is deleting takes on set. Guess high and the budget carries capacity nobody uses.

This estimator turns the variables you already know at the planning stage into a single number: codec, resolution, frame rate, camera count, and runtime. It scales a per-hour rate for each codec by pixel count and frame rate, multiplies across cameras, then adds the proxy and render headroom that most plans forget until the project is already full.

1. Camera configurations

Camera 1Custom

Camera

Codec

Resolution

Frame rate

2. Project overhead

Total storage

379 GB

316 GB raw footage plus 10% proxy overhead and 10% render/export headroom.

Storage mix

Raw footageProxy overheadRender headroom
379 GB including overhead

Breakdown

Custom

316 GB

316 GB/hr

Example use cases

  • Bidding a multi-camera shoot

    Price the storage line item on a three-camera corporate shoot before the quote goes out, with different codec options priced side by side.

  • Sizing cards and shuttle drives

    Work out how many camera cards a full shoot day needs, and whether a single shuttle drive holds the offload with room for a verified second copy.

  • Provisioning a cloud project

    Set a realistic starting capacity for a project before ingest begins, including the proxy set editorial will generate and the exports finishing will add.

  • Sanity-checking a vendor estimate

    Compare a post house or storage vendor number against an independent calculation before signing off on the capacity.

FAQ

The estimate uses a typical gigabytes-per-hour figure for each codec at 1080p and 24 fps, then scales it by pixel count and frame rate. For fixed-bitrate intra-frame codecs like ProRes and DNxHR, that math is close to what you will actually see on the cards, usually within a few percent. For variable-bitrate and RAW formats such as Blackmagic RAW, REDCODE, H.264, and H.265, the real file size depends on how much motion and detail is in the frame, so a static locked-off interview will land well under the estimate and a handheld action sequence can run over it. Treat the number as a planning figure and buy capacity above it.
Include all three. Camera originals are usually the largest single block, but they are not the whole project. Editorial generates a proxy set that typically adds 10 to 20 percent on top of the originals, and finishing adds renders, exports, conform media, graphics, and versioned masters that add roughly the same again. A plan that only counts camera originals is normally 20 to 30 percent short of the real footprint, and that gap shows up at the worst possible moment, near delivery.
For intra-frame codecs, file size scales close to linearly with frame rate because each frame is compressed independently. Shooting 48 fps instead of 24 fps roughly doubles the data rate at the same resolution and codec. That matters most on high-speed work: a few minutes of 120 fps material can occupy more space than an hour of standard-speed coverage. Long-GOP codecs like H.264 and H.265 scale less steeply because they compress across frames, so the increase is real but not proportional.
A reasonable working rule is 20 to 30 percent above the calculated total for a project with a known scope, and closer to 50 percent for anything with reshoots, unclear deliverable counts, or a client who versions heavily. Storage that fills to capacity mid-project is disruptive in a way that is hard to price: teams start deleting material they are not certain is safe to delete, which is how camera originals go missing. Buying margin up front is almost always cheaper than an emergency migration.