BRAW Proxy Workflow: When, How and How Much Storage

BRAW is designed for efficient decoding, but proxies can still transform a difficult edit. Multiple camera angles, high resolution, laptop hardware, remote collaboration, noise reduction, and network storage can make lightweight editorial media the sensible choice.

A proxy workflow succeeds when it reduces friction without weakening relink confidence. That requires consistent metadata, filenames, timecode, frame rate, color handling, and folder design.

When proxies are worth the work

Create proxies when one or more of these limits appears:

• The timeline drops frames with the required number of BRAW streams.
• Editors work on laptops or low-power systems.
• Media must travel over a slow network or internet connection.
• A remote editor does not need camera originals.
• Multicam playback is limited by storage or decode throughput.
• The project uses heavy effects, stabilization, or noise reduction.
• Editorial must begin before originals arrive at the finishing location.

Do not create proxies merely because the footage is RAW. Test native playback at the intended timeline resolution and debayer quality. Proxies add generation time, storage, transfer, and another media relationship to manage.

Proxy versus optimized media

The terms vary by application, but the practical distinction is portability and relink design.

Proxy media is usually explicit, portable editorial media that can be attached, copied to another system, or sent to a collaborator. It should have stable filenames and a controlled directory structure.

Optimized media is often application-managed performance media stored in a cache or internal location. It can be convenient on one workstation but less suitable for exchanging a project between facilities.

For a long project or remote team, explicit proxies are easier to inventory and rebuild.

Choose a proxy format by workflow

A proxy codec should decode easily on every editorial machine. Intraframe codecs often provide smoother seeking than highly compressed long-GOP delivery codecs, though they use more space.

Consider:

• Operating systems used by the team
• NLE support and hardware decoding
• Required proxy resolution
• Bit depth and color needs during editorial
• Audio channel layout
• Alpha-channel requirements, if any
• Network or shipping constraints

Common editorial proxies use ProRes Proxy, ProRes LT, DNxHR LB, or another intraframe format supported across the environment. A very low-bitrate H.264/H.265 proxy can be compact but may place more decode work on older systems and make frame-accurate scrubbing less responsive.

Resolution and aspect ratio

Proxy resolution should preserve the source aspect ratio and any framing metadata the editor needs. Half or quarter linear resolution is often enough, but unusual open-gate or anamorphic formats need attention.

Do not stretch a 6K open-gate source into a 16:9 proxy merely to match a preset. Letterbox, pillarbox, or use a compatible custom raster so framing decisions remain trustworthy. If the production uses desqueeze metadata, confirm the proxy and NLE display the intended image.

Preserve relink keys

Reliable relinking depends on stable identity. Preserve or document:

• Source filename
• Reel or camera roll name
• Start timecode
• Frame rate
• Clip duration and frame count
• Audio channel mapping
• Camera and date folder context

Avoid duplicate camera filenames. If the cameras can reset numbering, add a unique roll prefix before proxy generation or use reel metadata. Test a full offline-to-online relink before processing the entire shoot.

Color and RAW controls

Proxies are rendered images, so RAW adjustments used during generation can be baked into them. Decide whether editorial should see:

• A flat camera/log interpretation
• A normalized color-managed image
• A show LUT or viewing transform
• Burn-ins identifying the intended color path

The proxy is not the color master. Online finishing should return to BRAW originals and reapply the controlled RAW/color-management decisions. If editorial proxies include a look, record the transform so the online does not apply it twice.

Estimate proxy storage

Proxy storage comes from its own bitrate, not the BRAW compression ratio:

Proxy GB = proxy Mbps ÷ 8 × seconds ÷ 1,000

A 36Mbps proxy uses 4.5MB/s, about 16.2GB per hour. Ten hours of source would produce roughly 162GB before overhead. A 100Mbps proxy uses 45GB per hour.

This can be dramatically smaller than 6K BRAW, but multi-camera days still add up. Include proxy space on editorial drives and in transfer plans. Proxies are replaceable, so their backup priority may be lower than originals, but regeneration costs time.

Generation time is part of the schedule

Measure real transcoding speed as a multiple of real time. If the workstation processes a format at 2× real time, ten recorded hours need about five hours of generation. If heavy debayering, denoise, or a slow source drive lowers performance to 0.5×, the same work needs twenty hours.

Generation can be limited by:

• BRAW decode on CPU/GPU
• Source-drive read speed
• Destination-drive write speed
• Concurrent transcodes
• Resize and color transforms
• Burn-ins
• Audio processing

Do not schedule editorial delivery from a codec benchmark. Test a representative card with the final preset.

Burn-ins that help rather than obscure

Useful proxy burn-ins can include:

• Source filename
• Camera letter and roll
• Source timecode
• Date or unit
• Proxy watermark for external review

Keep the image area clear. A burn-in should help identify a shot when a file is detached from its database, not cover performance, subtitles, or framing guides.

Remote editorial workflow

For remote work, send:

• Proxies in a locked folder structure
• Project file or exchange file
• Audio and sync references
• LUTs or color-management notes
• Proxy manifest with counts, sizes, and checksums
• Clear path to request a missing or damaged clip

Use the same proxy root name across systems so path mapping remains predictable. Avoid asking every editor to rebuild a different folder layout.

When the edit is approved, return a project or timeline that references stable source identities. Online should test relinking early, before the deadline.

Proxy workflow checklist

1. Verify and protect camera originals first.
2. Decide whether native BRAW performance is genuinely insufficient.
3. Select a cross-platform codec and sensible raster.
4. Preserve aspect ratio, timecode, frame rate, audio, and unique clip identity.
5. Document the viewing transform.
6. Generate a small test batch.
7. Relink the test back to BRAW originals.
8. Measure storage and real generation speed.
9. Process the remaining media with logs.
10. Keep proxies replaceable and originals authoritative.

Use the BRAW calculator to budget source media first. Proxy planning begins after the camera-original volume is known, because the proxy is a performance layer—not a substitute for protecting the negative.

Sources and calculation notes

• 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.