Native R3D and BRAW Decoding: How We Built GPU-Accelerated Cinema Camera Support

If you shoot on a RED or a Blackmagic camera, your footage lives in a proprietary RAW format that most software cannot open. RED uses .r3d files. Blackmagic uses .braw files. These are not MP4s or MOVs. They store raw sensor data that needs to be debayered (converted from a mosaic of single-colour pixels into full-colour images) before you can even see what you shot.

Most video management tools simply ignore these formats and tell you to transcode first. We decided to support them natively.

Why this matters

Professional video production runs on these cameras. A RED KOMODO or a Blackmagic Pocket Cinema Camera 6K generates terabytes of footage per shoot. If FrameQuery cannot read those files directly, we are asking editors to transcode their entire library before they can search it. That is a non-starter.

Native decode means you drop your .r3d or .braw files into FrameQuery and they just work. No pre-processing step. No intermediate files eating up disk space.

How we handle R3D files

RED provides a C++ SDK for reading their proprietary format. We integrated it into our Rust backend, wrapping the SDK's C++ interfaces in safe Rust APIs with proper error handling and resource cleanup.

The critical part is GPU-accelerated debayering. Raw R3D frames need debayering, and doing it on CPU is slow, especially at 8K resolution. FrameQuery supports three decode paths:

• CUDA (Windows/Linux): Uses NVIDIA GPUs to pipeline CPU decode and GPU debayering in parallel. While the GPU processes one frame, the CPU is already decoding the next.
• Metal (macOS): Takes advantage of Apple Silicon's unified memory architecture for efficient GPU decode without the overhead of explicit memory transfers.
• CPU fallback: Works on any machine, no GPU required. Slower, but reliable.

The SDK also supports decoding at reduced resolutions (half, quarter, eighth, or sixteenth of the full frame). For proxy generation and search indexing, we do not need full 8K frames. Decoding at a lower resolution is dramatically faster and still provides more than enough detail for analysis.

How we handle BRAW files

Blackmagic's BRAW SDK takes a different approach to RED's, with its own object-oriented API and a more permissive licensing model. Our integration follows a similar pattern: wrap the SDK in safe Rust APIs, detect available GPU backends at startup, and select the fastest path automatically.

For proxy generation, we calculate the minimum decode resolution that still gives us enough pixels for the target proxy size. If the source is 6K and the proxy target is 720p, there is no reason to decode at full resolution. This saves enormous amounts of processing time across large libraries.

We also built resilient thumbnail generation. If one frame can't be decoded, the system tries alternatives at different points in the clip rather than failing entirely.

GPU-accelerated encoding

The decoded frames stream directly into the best available hardware encoder (NVENC on NVIDIA, Quick Sync on Intel, AMF on AMD) with software encoding as a fallback. The whole chain from RAW decode to MP4 output can be hardware-accelerated end to end.

What this enables

With native R3D and BRAW support, FrameQuery can index cinema footage the same way it indexes any other video. Drop in your camera originals, and the processing pipeline handles everything: decode the raw frames, extract transcripts from the audio track, run object detection, and generate scene descriptions via the cloud, then run face and voice recognition on-device. All of that gets saved to a local index you can search instantly.

No transcoding step. No waiting hours for ProRes exports before you can even start searching.

Join the waitlist to try it with your own camera originals.