Sizing a Video Project Before the Shoot: Footage, Proxies, Backups and Upload Time

Storage trouble on a video job almost never shows up on the shoot itself. It shows up on day two of the edit. The card dump has filled the laptop, the proxies won’t fit beside the originals, and someone says “we’ll just put a copy in the cloud tonight”. Then the progress bar says 63 hours. All of that can be worked out before anyone presses record. The numbers are just bitrate, hours and upload speed, and you can run them in ten minutes with a calculator.

This guide plans one realistic project from start to finish: a two-camera, three-day interview shoot. We’ll build the drive budget layer by layer. The underlying formulas already have their own guides: how bitrate turns into file size, why WAV files are the size they are, and why a 100 Mbps line downloads at 12 MB/s. This one assumes them and does the planning.

Start with recorded hours, not the running time of the film

The finished piece might be twelve minutes long, but that tells you nothing about storage. What you need is how long each camera will actually be recording. Interviews roll long, B-roll gets shot generously, and two cameras means two streams of everything.

For our example:

• 2 cameras
• 3 shoot days
• about 2.5 hours of recorded footage per camera per day

That’s 2 × 3 × 2.5 = 15 hours of camera originals. Most of the planning errors I see begin here, when someone sizes the drives from the edit length or from one camera’s footage.

Camera originals: one multiplication per hour

Your camera records at a fixed bitrate for each mode, and the spec sheet or manual lists it. Long-GOP 4K modes on current mirrorless and cinema cameras commonly sit somewhere between 100 and 200 Mbps, and intra-frame and raw modes go far higher. Use your camera’s real figure for the mode you’ll shoot in, not a generic one.

The Video Bitrate & File Size Calculator gives recommended delivery bitrates for a chosen resolution, frame rate and codec. It doesn’t have a field for typing in an arbitrary camera bitrate. For camera originals, do this one by hand. Here’s a shortcut worth memorising:

GB per hour = Mbps × 0.45

That’s just Mbps × 3600 seconds ÷ 8 bits ÷ 1000, folded into one constant. Our cameras record 4K 10-bit H.265 at 150 Mbps:

150 × 0.45 = 67.5 GB per hour
67.5 × 15 hours = 1,012.5 GB

So the camera originals alone are just over a terabyte. Make this layer the most precise one in your plan. It’s the only layer you can’t regenerate, and it’s the one the backup plan is built around.

Sound: real, but small next to the picture

Say the sound recordist runs one recorder with four mono tracks (two lavs, a boom and a room mic) at 48 kHz/24-bit. The recorder rolls whenever either camera does, so call it 2.5 hours a day, 7.5 hours in total.

The Sample Rate & Bit Depth File Size Calculator does this directly. Set 48 kHz, 24-bit, mono and a duration of 7:30:00 and it returns about 3.89 GB per track. The channel menu offers mono, stereo, 5.1 and 7.1, but not four discrete tracks, so multiply the mono figure by four yourself:

Recording format	Per track (7.5 h)	Four tracks
48 kHz / 24-bit	3.89 GB	15.6 GB
48 kHz / 32-bit float	5.18 GB	20.7 GB

Many field recorders now default to 32-bit float, which adds a third to the size. Even so, sound comes to about 2% of the camera originals. Treat it as a rounding item in the budget. It still belongs in the backup plan, though. Losing the boom track is as bad as losing a camera card.

Proxies are a second, smaller copy of every hour

If you cut 4K H.265 on a laptop, you’ll almost certainly generate proxies: lightweight edit copies that your editing software swaps in for the heavy originals. Their size depends on the proxy format you pick, and the gap between formats is large:

Proxy format	Approx. bitrate	15 hours
ProRes 422 Proxy, 1080p30	~45 Mbps	~304 GB
H.264 1080p30	8 Mbps	54 GB

The 45 Mbps figure is Apple’s published ProRes 422 Proxy rate for 1080p at 29.97 fps. The bitrate calculator doesn’t include ProRes Proxy in its codec list, so that row is hand arithmetic (45 × 0.45 × 15). The H.264 row matches the calculator’s recommended 1080p30 H.264 rate. ProRes Proxy is far easier for the editing machine to decode, and H.264 proxies are six times smaller. On a laptop with limited SSD space, that trade is worth thinking about before you start transcoding.

We’ll plan with ProRes Proxy, the heavier option.

Cache, renders and exports: give them a line of their own

Editing software writes render files, waveform caches, optimised media and every export you make. None of it shows up in a spreadsheet of camera files, and all of it shares the drive with your footage. Give it an explicit allowance rather than hoping. Here we’ll use 15% of the working set.

Now add up the editing drive:

Layer	Size	Can it be regenerated?
Camera originals	1,012.5 GB	No
Sound (24-bit)	15.6 GB	No
ProRes proxies	303.8 GB	Yes, from originals
Cache / renders (15%)	199.8 GB	Yes
Working set	≈1,532 GB

A 2 TB SSD holds that at about 77% full. That leaves room for a pickup day, but not for a second project.

The 3-2-1 rule multiplies the irreplaceable layer, not everything

The standard backup rule is three copies, on two different kinds of storage, with one offsite. People often apply it to the whole working set, multiply 1.53 TB by three and go shopping for nearly 4.6 TB. That’s more than you need.

Only the right-hand column of the table above has to be triplicated. Proxies and cache can be rebuilt from the originals. Rebuilding them is slow and annoying, but nothing is lost. The irreplaceable layer is the camera originals plus sound, about 1,028 GB:

irreplaceable × 3  = 1,028 × 3 ≈ 3,084 GB
+ proxies (once)   ≈   304 GB
+ cache (once)     ≈   200 GB
                   ≈ 3.59 TB of total capacity

In hardware terms, that might be:

1. Edit SSD (2 TB): originals, sound, proxies, cache. Copy one.
2. Local backup HDD (2 TB): originals and sound only. Copy two, on a different kind of media.
3. Offsite: cloud storage or a drive kept at another address. Originals and sound. Copy three.

Two quick checks before you buy. Drives are sold in decimal terabytes, while some operating systems report binary units, so a “4 TB” drive shows up as about 3.64 TiB. (The bandwidth guide covers GB versus GiB.) And copy two only counts once it has been verified: a checksum or a copy tool that compares files after writing. Dragging a folder and assuming it worked doesn’t count.

The offsite copy is where the schedule breaks

Copy three is usually where the plan falls apart, because it goes out over your upload connection, and upload is usually the slow direction. Our example uses a plan of 500 Mbps down and 40 Mbps up, which is common for cable.

Put 1.03 TB and 40 Mbps into the Bandwidth & Download Time Calculator. (It’s labelled as a download calculator, but the arithmetic is the same in either direction. Just enter your upload speed.)

• Theoretical: 57h 13m 20s
• With the ~10% real-world overhead box ticked: 63h 34m 26s

That’s more than two and a half days of a saturated uplink, and while it runs your video calls and the editor’s own syncing all slow down. Doing it during the shoot instead shows the other half of the problem. Each shoot day produces 2 cameras × 2.5 h × 67.5 GB = 337.5 GB of originals:

Daily footage	Upload speed	Time to send one day’s footage
337.5 GB	40 Mbps	18h 45m (≈20h 50m with overhead)
337.5 GB	100 Mbps	7h 30m (≈8h 20m with overhead)

To keep up you need about 337.5 GB × 8 ÷ 86,400 s ≈ 31 Mbps running nonstop around the clock, so 40 Mbps keeps up only on paper. Any interruption means you fall behind. Two practical alternatives are an offsite drive that someone carries home each night, or uploading from a location with a faster connection. When a trip across town is quicker than 63 hours of uploading, carrying a drive is the better backup.

Client delivery is the small upload, unless they want the rushes

The finished film is a different scale of problem. A 12-minute 4K30 master at the bitrate calculator’s recommended H.264 rate (45 Mbps video plus 192 kbps audio) comes out at 4.07 GB. At 40 Mbps up that’s 13m 34s, or about 15 minutes with overhead. That’s fine for a review link. ProRes masters or several versions multiply it, but you’re still dealing in minutes.

Things change if the contract says the client receives all the footage. That’s the full terabyte again, and the 63-hour figure becomes a delivery date. Agree on the handover method when you quote: a shipped drive with a checksum list, or a cloud transfer with a realistic timeline. Agreeing late in the edit tends to produce surprised emails.

Run your own numbers before you buy drives

The order is the same for every project. Count recorded hours across all cameras. Multiply by each camera’s bitrate × 0.45. Add sound, proxies and a cache allowance. Triplicate only what can’t be regenerated. Then check the offsite copy against your real upload speed.

Use the Video Bitrate & File Size Calculator for delivery-file sizes across H.264, H.265, AV1 and ProRes, and the Sample Rate & Bit Depth File Size Calculator for the sound recorder. The Bandwidth & Download Time Calculator tells you whether the offsite copy will be finished tonight or on Thursday.