Planning Storage for Video Projects

Storage is the one part of video production that can be predicted exactly, and it is the part most often discovered as an emergency. A drive fills on the second day of a three-day shoot, or a project stops rendering at the deadline because the cache had nowhere to go.

None of this requires a surprise. File size is bitrate multiplied by duration, and every number in that equation is knowable before you press record. This guide covers the arithmetic, what genuinely consumes space during a project, how to decide what to keep, and what an archive has to contain to still open in five years.

The Only Calculation You Need

Bitrate is quoted in megabits per second. Storage is measured in megabytes. There are eight bits in a byte, so:

megabytes per second  =  bitrate in Mbps ÷ 8
gigabytes per hour    =  (bitrate in Mbps ÷ 8) × 3600 ÷ 1000

A 100 Mbps camera format therefore records 12.5 MB every second, 750 MB every minute, and roughly 45 GB every hour. That is one camera, running continuously.

These are ranges rather than fixed values, because every camera and every codec sits somewhere different within them. Take the actual bitrate from your own camera's specification and run the division — that number is exact, and it is the one worth writing on the shoot plan.

What Actually Fills the Drive

The camera originals are usually not the largest thing in a finished project folder, which is why storage estimates based only on footage come out short.

Proxies. A full set of low-resolution stand-ins for every clip, including the takes you never used. On a large shoot this can rival the originals.

Render and cache files. Editors write background renders, waveform caches, thumbnail caches and optimised media as you work. These grow continuously and are usually stored somewhere you are not looking. Clearing them between projects recovers more space than any other single action.

Autosaves. Small individually, and there may be hundreds by the end of a long project.

Export versions. Every draft, every platform variant, every version sent for review. These accumulate faster than anything else because each one feels too small to matter.

Duplicated media. The same clips imported twice, or copied into a second project folder for a related edit. This is the one that organisational discipline prevents outright, which is part of why the folder scheme in project organisation that survives fifteen revisions is worth having.

Estimating Before a Shoot

Deciding What to Keep

At the end of a project, sort everything into three categories.

Keep permanently. The camera originals, the project file, the fonts and graphics it depends on, and the delivered exports. This is the archive.

Keep briefly. Draft exports and review versions, until the job is signed off and you are confident nothing is coming back.

Delete now. Proxies, caches, optimised media, autosaves. Every one of these is regenerable from the archive, and together they are usually the largest group.

The temptation that costs the most later is deleting source footage and keeping only the export. An export is a heavily compressed, single-resolution, single-aspect-ratio, colour-locked version of the project. Any future request — a different crop, a corrected caption, a new language, a higher resolution — needs the source. The size difference between a delivery file and its originals is set out in the table above, and the gap is the price of being able to do the work again.

Where storage genuinely forces a choice, consider dropping the acquisition quality on future shoots rather than discarding past sources. A project shot at a sensible bitrate for its purpose costs less across its whole life than a project shot at maximum and then thrown away — and choosing that bitrate sensibly is the subject of how bitrate, resolution and quality relate.

Drives, Speed and the Bottleneck That Is Not Capacity

Capacity is the number people plan around and speed is the one that decides whether a working day is pleasant. A drive with plenty of room that cannot sustain the read rate your timeline demands will stutter during playback, and no amount of free space fixes it.

The requirement follows directly from the same arithmetic. A single 4K stream at a high bitrate might need a few hundred megabytes per second sustained; a multi-camera timeline playing three angles at once needs that several times over. Where the drive cannot supply it, the editor either drops frames or falls back to rendering, and both feel like the software being slow rather than the storage being wrong.

This is the actual argument for proxies. They exist to reduce the data rate the timeline demands, not to save space — the proxies themselves take more space, not less. Editing from small stand-ins and relinking to the originals at export lets a modest drive handle material it could never play natively.

Two practical consequences. Keep active projects on your fastest storage and archives on your cheapest, because the two have opposite requirements. And when playback stutters, check the drive's sustained throughput before blaming the machine — it is the more common cause and the cheaper one to fix.

Deleting Safely

The riskiest moment in storage management is the clear-out, because it is done under pressure when a drive is already full.

Do it in a fixed order, from the most regenerable to the least. Caches and rendered previews first: they cost nothing but time to rebuild. Then proxies, which can be regenerated from the source. Then draft exports for projects that have been signed off. Only after all three should you consider anything that cannot be recreated, and by that point you have usually recovered enough.

The rule that prevents the expensive mistake is simple: never delete anything from a project that has not been archived. If the archive exists and has been verified, deleting the working copy is safe. If it does not, you are not clearing space, you are gambling.

An Archive That Reopens

The failure mode of archives is not lost files. It is files that survive and no longer work together.

Put the fonts in. A project reopened years later with a substituted typeface renders wrong and does not announce it. Put the graphics and any generated assets in, rather than links to where they used to be. Keep the project file in its native format, and consider also exporting an interchange format, because editing applications change more than file formats do.

Keep the delivery masters rather than only the platform variants, and keep a short text file describing what the project was and what was delivered. In three years that file will save more time than any folder structure.

Finally, store the archive as one unit. A zip or a single folder that contains everything, so that restoring it is one operation and there is nothing to reassemble. What formats to keep it in comes back to the difference between editing and delivery codecs, described in video codecs explained.

Next Steps

Find your editor's cache directory and look at how large it is. On a machine that has run several projects it is frequently tens or hundreds of gigabytes, all of it regenerable, and clearing it takes a minute.

Then do the arithmetic for your next shoot before it happens: bitrate divided by eight, times seconds, times cameras, plus transcodes, plus half again. Write the number down and compare it to the space you actually have. That single calculation prevents the most disruptive problem in production, and the rest of the technical material sits under formats, specs and delivery.