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. Both store raw sensor data that needs to be debayered (converted from a mosaic of single-color pixels into full-color images) before you can see what you shot.

Most video management tools do not open these formats and require a transcode first. FrameQuery decodes 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. Without native decode, editors would have to transcode their entire library before they could search it.

With native decode, you add .r3d or .braw files to FrameQuery and it indexes them. There is no pre-indexing step and no intermediate files on disk.

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.

Debayering runs on the GPU. 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 on-device frame extraction and search indexing, we do not need full 8K frames. Decoding at a lower resolution is faster and provides 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 on-device frame extraction, we calculate the minimum decode resolution that still gives us enough pixels for the extracted frame size we need for analysis. If the source is 6K and the target is 720p, there is no reason to decode at full resolution. This cuts processing time across large libraries.

If one frame cannot be decoded, thumbnail generation tries other points in the clip rather than failing.

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.

There is no transcoding step and no wait for ProRes exports before searching.

Download FrameQuery to try it with your own camera originals.