Every storage decision in post is secretly a bitrate decision. How many drives the shoot needs, whether the NAS keeps up, why the export took four hours, why the “same” clip is 4GB from one camera and 40GB from another… all of it comes down to how many megabits per second a codec spends. And those numbers are weirdly hard to find in one place: Apple’s live in a PDF appendix, Avid’s in a knowledge-base table, camera rates in per-model help pages. So here they all are, in one sheet, with the storage math to turn any of them into gigabytes per hour in your head.
Last updated: August 2026. No affiliate links on this page; it’s a reference. Numbers come from the manufacturers’ own documents (Apple’s ProRes white paper, Avid’s DNxHR specifications, each camera maker’s published specs), read early August 2026. The one number to memorize before the tables: GB per hour = Mbps × 0.45.
TLDR
If you just want the answer: ProRes 422 is 117 Mbps at 1080p24 and 471 at UHD 24, HQ is roughly 1.5x that, and every hour of UHD ProRes HQ eats 318GB. DNxHR SQ and HQ are Avid’s equivalents at similar weights. Camera long-GOP files are 5 to 10 times smaller than the intermediates you’ll cut them as, which is the entire storage story of modern post. Multiply any Mbps by 0.45 and you have GB per hour; that trick outlives every table below.
ProRes (Apple’s published targets)
From Apple’s ProRes white paper, which prints target rates per resolution and frame rate. ProRes is variable bitrate in practice, hovering near these targets; easy footage comes in under, and the encoder deliberately won’t overspend on frames that can’t get better.
1080p
| Flavor | 24p | 24p storage | 30p | 30p storage |
|---|---|---|---|---|
| 422 Proxy | 36 Mbps | 16 GB/hr | 45 Mbps | 20 GB/hr |
| 422 LT | 82 Mbps | 37 GB/hr | 102 Mbps | 46 GB/hr |
| 422 | 117 Mbps | 53 GB/hr | 147 Mbps | 66 GB/hr |
| 422 HQ | 176 Mbps | 79 GB/hr | 220 Mbps | 99 GB/hr |
| 4444 | 264 Mbps | 119 GB/hr | 330 Mbps | 148 GB/hr |
| 4444 XQ | 396 Mbps | 178 GB/hr | 495 Mbps | 223 GB/hr |
UHD (3840×2160)
| Flavor | 24p | 24p storage | 30p | 30p storage |
|---|---|---|---|---|
| 422 Proxy | 145 Mbps | 65 GB/hr | 182 Mbps | 82 GB/hr |
| 422 LT | 328 Mbps | 148 GB/hr | 410 Mbps | 185 GB/hr |
| 422 | 471 Mbps | 212 GB/hr | 589 Mbps | 265 GB/hr |
| 422 HQ | 707 Mbps | 318 GB/hr | 884 Mbps | 398 GB/hr |
| 4444 | 1061 Mbps | 477 GB/hr | 1326 Mbps | 597 GB/hr |
| 4444 XQ | 1591 Mbps | 716 GB/hr | 1989 Mbps | 895 GB/hr |
DCI 4K (4096-wide) runs about 7% heavier than UHD across the board: 422 HQ at 24p is 754 Mbps, 339 GB/hr. Apple’s 24p rows cover 23.976 and true 24. And a practical translation for the two flavors everyone debates: at 1080p, the step from 422 to HQ costs 26 GB/hr; at UHD it costs 106 GB/hr. That’s why “shoot HQ, edit 422” is a real strategy at 4K and a rounding error at 1080.
DNxHR (Avid’s equivalents)
Avid publishes these in megabytes per second; converted here to Mbps for comparison. HQ and HQX share a data rate (HQX adds 12-bit precision, not size). The legacy DNxHD names were literally the bitrate: DNxHD 36 is LB at 1080p23.976, DNxHD 220 is HQ at 29.97.
| Flavor | 1080p 23.976 | UHD 23.976 | UHD storage | ProRes cousin |
|---|---|---|---|---|
| DNxHR LB | 34 Mbps | 137 Mbps | 62 GB/hr | 422 Proxy |
| DNxHR SQ | 110 Mbps | 441 Mbps | 198 GB/hr | 422 |
| DNxHR HQ/HQX | 166 Mbps | 666 Mbps | 300 GB/hr | 422 HQ |
| DNxHR 444 | 333 Mbps | 1333 Mbps | 600 GB/hr | 4444 |
What cameras hand you
Acquisition codecs are the other half of the math, and the spread is enormous:
| Format | Typical rates | The character |
|---|---|---|
| Sony XAVC S (H.264 long-GOP) | 4K60: 150 to 200 Mbps | Small files, CPU-hungry to scrub |
| Sony XAVC HS (HEVC) | 4K: 45 to 200 Mbps modes | Smaller still, hungrier still |
| Sony XAVC S-I (all-intra) | 4K60: 600 Mbps | Big, edits like butter |
| Canon XF-AVC | 260 Mbps 4K long-GOP to 600 Mbps intra | Both personalities, one camera |
| Blackmagic RAW 12:1 → 3:1 | ~650 Mbps to ~2.6 Gbps (6K30) | Scales with sensor and fps, not resolution alone |
| RED R3D (Komodo 6K) | ~0.9 to 2.2 Gbps by quality | The full-fat cinema pipeline |
| ProRes RAW / RAW HQ | Content-dependent; between 422 and 4444 territory | Constant quality, so noisy footage runs bigger |
Notice the shape of the problem: a 150 Mbps camera file becomes a 707 Mbps ProRes HQ intermediate the moment you transcode UHD for a smooth edit. Your storage didn’t grow; your codec did, by design. That’s the trade the proxy workflow guide is built around, and it’s why the NAS guides on this site obsess over sustained throughput. One BRAW caveat before you quote it: those constant-ratio numbers scale with the sensor, so a bigger sensor at the same ratio writes more data; quote per-camera, not per-ratio.
Delivery: H.264, HEVC, AV1
Going the other direction, delivery codecs spend a fraction of the bits. YouTube’s published upload guidance wants just 8 Mbps for 1080p SDR and 35 to 45 Mbps for 4K (roughly double for high frame rate, more for HDR). The efficiency ladder across generations: HEVC reaches H.264 quality at roughly half the bitrate (the formal verification tests measured about 59% average savings), and AV1 buys another real step; Netflix reported 20% improvement over its VP9 encodes, which puts a practical AV1-vs-H.264 rule of thumb at 40 to 50% smaller for matched quality. That’s the whole story of why platforms keep re-encoding your uploads into newer codecs: the same library, half the bandwidth bill.
For your own H.264/H.265 archives and terminal deliverables, quality-targeted encoding beats bitrate-targeted: x264’s CRF scale defaults to 23, HandBrake’s docs recommend RF 20 to 24 for 1080p and 22 to 28 for 4K, and each step of 6 roughly doubles or halves the file. Full settings-level detail lives in the encoder presets explainer.
The storage math (learn one number)
Codecs are specified in megaBITS per second; drives and files live in megaBYTES. Divide by eight, and from there: GB per hour = Mbps x 0.45. (Mbps x 3,600 seconds, over 8, over 1,000.) That single factor reproduces Apple’s own storage tables exactly.
- ProRes 422 HQ, UHD 24p: 707 x 0.45 = 318 GB per hour.
- A 150 Mbps HEVC camera file: 150 x 0.45 = 67.5 GB per hour, so a day of interviews fits where one hour of finishing codec goes.
- Reverse it for throughput: that 707 Mbps file needs ~88 MB/s sustained just to play one stream. Four streams in a multicam is 350+ MB/s, and now you know why the 10GbE guide exists.
One more gotcha for the road: operating systems mix decimal and binary units. 67.5 GB is 62.9 GiB, and Windows labels GiB as “GB,” which is why your card “shrank” in Explorer. Nothing is wrong; the units are lying to each other. The storage calculator does all of this math per-project if you’d rather not.
Three misconceptions this table kills
“Higher bitrate always looks better.” Only inside one codec, and only up to transparency. Across codecs the comparison is meaningless without naming them: 60 Mbps of HEVC matches 120 of H.264. Apple’s encoder documentation says it plainly: past the point where bits improve fidelity, ProRes refuses to spend them.
“Transcoding ruins quality.” Long-GOP delivery codecs degrade with each re-encode; intra-frame intermediates barely do. Apple’s own multigeneration testing shows 422 and HQ visually identical to source after nine-plus generations (Proxy and LT have less headroom). Transcode camera originals once to a proper intermediate and round-trip in that; the rule falls straight out of the data.
“10-bit means bigger files.” It means fewer banding artifacts at the same size. Encoder documentation recommends special anti-banding modes specifically for 8-bit and starved 10-bit encodes; give a gradient-heavy shot (skies, log footage) 10 bits and the sky stops posterizing without the file growing to match. The color spaces reference picks up this thread properly.
In conclusion
Bitrate is the exchange rate between image quality and everything that costs money in post: drives, network, render time, upload windows. The tables above are the posted rates; the x 0.45 trick is the mental currency converter; and the linked guides (the storage calculator, proxy workflow, encoder presets, and delivery specs pages) are where each number turns into a buying or workflow decision. This page gets re-verified when Apple, Avid, or the platforms revise their documents. If a number moved before I caught it, the comments are right there.
