BRAW File Size Guide: GB per Minute and TB per Shoot

BRAW file size is mainly determined by five inputs: sensor resolution, frame rate, compression setting, recorded duration, and whether the encoder is using Constant Bitrate or Constant Quality. A production buffer then turns the codec estimate into a working storage allocation.

The core calculation is simple. The hard part is using the right data rate and applying the result to the whole production rather than a single perfect take.

The basic file-size formula

When the data rate is expressed in megabytes per second:

File size in GB = data rate in MB/s × duration in seconds ÷ 1,000

For one minute, multiply MB/s by 60 and divide by 1,000. For one hour, multiply by 3,600 and divide by 1,000.

At 100MB/s, that produces:

• 6GB per minute
• 360GB per hour
• 720GB for two recorded hours

Add a 20% production buffer and the two-hour allocation becomes 864GB. The buffer does not change the codec. It reserves room for retakes, pre-roll, unplanned coverage, camera tests, slates, pickup shots, and operational uncertainty.

Why resolution matters

More photosites per frame generally require more data at the same bit depth, frame rate, and compression ratio. Moving from 4K to 6K is not a small step because the change happens across both width and height.

For example:

• 4096 × 2160 contains about 8.85 million pixels.
• 6144 × 3456 contains about 21.23 million pixels.
• 12288 × 6480 contains about 79.63 million pixels.

Six-kilopixel capture in that example contains around 2.4 times as many pixels per frame as 4K DCI. Twelve-kilopixel capture contains about nine times as many as 4K DCI. Compression makes the recorded difference smaller or larger depending on settings, but the pixel count explains why high-resolution BRAW can become a multi-terabyte workflow quickly.

Sensor windows and aspect ratios also matter. 6K 2.4:1 records fewer vertical pixels than 6K 16:9, so it should not be assigned the same data rate merely because both are called “6K.” Use the exact dimensions where possible.

Why frame rate scales storage

Each extra frame is another compressed image. If every other setting remains constant, moving from 24fps to 48fps approximately doubles the data rate and file size. Moving from 24fps to 60fps multiplies it by 2.5.

This creates an easy production mistake: calculating slow-motion storage using the timeline frame rate instead of the sensor recording frame rate. A clip captured at 60fps and played at 24fps lasts 2.5 times longer on the timeline, but the camera still recorded 60 frames for every second of real-world action.

Always plan acquisition storage from the recording frame rate.

How the compression ratio changes size

At the same resolution and frame rate, 3:1 uses about four times the data of 12:1. The relative sequence is not evenly spaced:

• 3:1 to 5:1 reduces the stream to about 60%.
• 5:1 to 8:1 reduces it to about 62.5%.
• 8:1 to 12:1 reduces it to about 66.7%.

Those reductions compound across every card, backup, transfer, and archive. A choice that saves 200GB on one recorded hour can save several terabytes across a multi-camera week.

Storage savings should not be evaluated without image tests. Fine texture, high noise, fast motion, keying, reframing, and aggressive grades may benefit from lower compression. The correct setting is the smallest data footprint that still passes the project’s visual and technical requirements.

Constant Quality needs a range

Q0, Q1, Q3, and Q5 do not map to a single guaranteed MB/s value. They let the encoder use more data on difficult frames and less on simple frames. A file-size calculation should therefore show a low and high estimate.

For capacity planning:

• Use the upper estimate when deciding how many cards or drives to buy.
• Use the upper estimate when checking media write speed.
• Use the lower estimate only as a possible best case, not a schedule guarantee.
• Test with the noisiest, busiest, fastest-moving expected scene.

One quiet interview cannot validate a Q-mode plan for a concert, forest, water sequence, or handheld night exterior.

Worked example: one hour of 6K at 24fps

Using a ratio-based estimate, 6144 × 3456 at 24fps and 5:1 is roughly 156.7MB/s before camera-specific differences. That is approximately:

• 9.4GB per minute
• 564GB per hour
• 677GB with a 20% production buffer

These rounded figures use the same model as the calculator. Calculations use the unrounded rate before formatting the displayed result.

Now expand the scenario to two cameras recording two hours each:

564GB × 2 hours × 2 cameras = 2.256TB of base camera originals

With a 20% buffer, allocate about 2.71TB for acquisition. Two verified working copies require about 5.42TB of available destination capacity. That total still excludes proxies, project files, audio, graphics, exports, and long-term archive.

Decimal GB versus binary GiB

Drive manufacturers use decimal units:

• 1GB = 1,000,000,000 bytes
• 1TB = 1,000GB = 1,000,000,000,000 bytes

Some operating systems report binary units even when the interface labels are confusing:

• 1GiB = 1,073,741,824 bytes
• 1TiB = 1,024GiB

A 1TB drive is about 931GiB. The bytes did not disappear; the counting unit changed. Formatting, filesystem structures, device overprovisioning, and the need to avoid filling a drive completely can further reduce practical recording capacity.

BRAW Planner uses decimal GB and TB because that matches how storage products are advertised. The record-time mode lets you reserve 10%, 20%, or 30% capacity rather than pretending every advertised byte is available for a take.

From file size to a complete storage budget

A proper budget has at least four layers:

1. Acquisition media: enough cards or SSDs to cover the rolling schedule and offload turnaround.
2. Primary working storage: a verified copy for editorial or data management.
3. Second verified copy: a separate device or location before source media is cleared.
4. Archive and project overhead: originals plus audio, proxies, caches, graphics, exports, and version history.

Do not multiply only the shooting ratio. Track recorded hours per camera. A 12-hour day does not mean 12 recorded hours, but event and documentary work can accumulate far more footage than a narrative schedule with carefully controlled takes.

A fast planning checklist

• Use exact pixel dimensions, not only “4K” or “6K.”
• Calculate from sensor recording fps, not timeline fps.
• Keep Constant Quality as a range.
• Add a visible 20–30% production buffer when uncertainty is high.
• Multiply by camera count and recorded hours.
• Budget at least two verified copies before formatting source media.
• Include proxies, audio, project files, and exports separately.
• Test the real camera and media for the longest expected roll.

Use the BRAW file-size calculator for the first pass, then move the result into a full media inventory. A file-size number becomes useful only when it prevents a card shortage, a missed offload window, or an incomplete backup.

Sources and calculation notes

• Blackmagic Pocket Cinema Camera technical specifications: camera-specific formats and storage-rate reference tables.
• Blackmagic RAW overview: manufacturer information about the codec and encoding modes.
• BRAW Planner methodology: the estimation formulas, unit conventions and limitations used on this site.

Workflow suggestions in this guide are planning guidance, not a claim that a particular camera or drive has been tested by the author.