How to Organise Terabytes of RED and Blackmagic Footage Without Transcoding

If you shoot on a RED KOMODO, DSMC2, V-RAPTOR, Blackmagic Pocket Cinema Camera, or URSA, you know the problem. Every shoot produces hundreds of gigabytes of proprietary RAW files. Over a year, that becomes terabytes. Over a career, it becomes an unmanageable archive that nobody can navigate.

The standard advice is to transcode everything to ProRes or DNxHR, organise the transcodes, and search from there. That advice was fine when storage was cheap and time was infinite. In reality, transcoding terabytes of cinema RAW footage takes days of machine time and doubles your storage requirements.

There is a better approach.

The transcoding problem

Let us be specific about what transcoding costs.

A single day of shooting on a RED V-RAPTOR at 8K produces roughly 500 GB to 1 TB of .r3d files. Transcoding that to ProRes 422 HQ for organisation purposes means:

• Time: 8 to 16 hours of encoding, depending on your hardware and resolution
• Storage: The ProRes files will be roughly the same size as the originals, so you now need double the storage
• Management: You have two copies of every clip (RAW original + transcode) that need to stay in sync

Multiply that by every shoot you have done in the last five years. A busy production company might have 50 to 100 TB of archived footage. Transcoding all of it for organisation purposes is simply not practical.

And here is the thing: you do not need the transcodes for organisation. You need them because your tools cannot read the originals.

FrameQuery reads the originals

FrameQuery decodes R3D and BRAW files natively using the official RED and Blackmagic SDKs. No transcoding step. No intermediate files.

FrameQuery also understands cinema camera folder structures. RED cameras store clips as folder hierarchies containing multiple .r3d segment files. Blackmagic cameras have their own folder conventions. FrameQuery detects these folder-based clips automatically and treats them as single clips rather than scattered files.

When FrameQuery encounters an .r3d or .braw file (or a folder clip containing them), it:

1. Opens the file directly using the vendor SDK
2. Decodes frames at an appropriate resolution for analysis (typically quarter or eighth resolution, which is faster and sufficient for search indexing)
3. Extracts the audio track for transcription
4. Runs the full processing pipeline (transcription, object detection, face recognition, scene descriptions)
5. Stores the results in a local search index

Your original camera files stay exactly where they are. No transcodes are created. No extra storage is consumed.

The workflow: camera card to searchable archive

Here is a practical step-by-step for getting your cinema footage organised.

After the shoot: ingest as normal

Copy your camera cards to your storage system however you normally do. Mirror the card structure, use a tool like Hedge or Silverstack, or simply drag and drop. Nothing changes about your ingest workflow.

Your folder structure might look like:

/Volumes/Archive/
  2026/
    ClientName_Jan/
      CamA/
        A001_C001.r3d
        A001_C002.r3d
        ...
      CamB/
        B001_C001.braw
        B001_C002.braw
        ...
    ClientName_Feb/
      ...

Point FrameQuery at your archive

Add your archive root folder (or individual project folders) as source folders in FrameQuery. The app scans the directory structure and discovers every video file, including R3D and BRAW files that most tools skip.

Process the footage

Start processing. FrameQuery generates lightweight proxies from the RAW files using GPU-accelerated decoding and sends them for AI analysis. This happens in the background. You do not need to babysit it.

The processing uses the minimum decode resolution needed for accurate analysis. An 8K RED file does not need to be decoded at full 8192x4320 for object detection. Quarter resolution (2048x1080) provides plenty of detail for search indexing while decoding dramatically faster.

Search and organise

Once processed, your cinema footage is fully searchable alongside everything else in your library. Search works the same whether the source file is an MP4, a ProRes MOV, an R3D, or a BRAW:

• Search transcripts across all your interview footage
• Find specific people across all cameras and shoots
• Locate shots by description: "crane shot of building exterior," "close-up product detail"
• Search for objects: "car," "phone," "equipment on table"

The search index does not care about the source format. It indexes the content, not the container.

GPU acceleration makes it practical

Cinema RAW files are computationally expensive to decode. Debayering (converting raw sensor data into viewable images) requires significant processing power. FrameQuery uses GPU acceleration to make this fast enough for batch processing.

On NVIDIA GPUs (Windows/Linux): CUDA-accelerated decode with double-buffered pipeline. While the GPU processes frame N, the CPU is already loading frame N+1. Pinned memory transfers minimise GPU-CPU bottlenecks.

On Apple Silicon (macOS): Metal-accelerated decode with shared memory buffers. The unified memory architecture on M-series chips means CPU-decoded data is already accessible to the GPU without explicit transfers.

CPU fallback: If no supported GPU is available, decode falls back to CPU. Slower, but it works on any machine.

The GPU-accelerated path is fast enough that processing a day's worth of RED footage takes a fraction of the shooting time, not a multiple of it.

What about the existing archive?

The real value is retroactive. You probably have years of footage sitting on drives that you have never organised because the prospect of transcoding it all was too daunting.

FrameQuery can process your back catalog incrementally. Start with the drives you access most often. Add older archives as time allows. Each batch you process expands your searchable library.

There is no requirement to process everything at once. You can add drives and folders over time, and new footage merges into the same searchable index. Five years of RED footage from different projects, cameras, and shoots, all searchable from one interface.

Working with mixed formats

Most production companies do not shoot exclusively on cinema cameras. Your archive likely includes a mix of:

• R3D files from RED cameras
• BRAW files from Blackmagic cameras
• ProRes or DNxHR from other cameras or transcoded dailies
• MP4 or MOV files from smaller cameras, phones, or screen recordings
• MXF files from broadcast cameras

FrameQuery handles all of these. The native R3D and BRAW decoding sits alongside standard FFmpeg-based decoding for everything else. Your searchable archive is format-agnostic. Search "interview with client" and get results from your RED A-cam, your Blackmagic B-cam, and your iPhone behind-the-scenes clip, all ranked by relevance.

Practical tips for cinema camera archives

A few things we have learned from working with large RAW archives:

Keep your camera originals. This should be obvious, but it is worth emphasizing. R3D and BRAW files are your master quality source. FrameQuery indexes them without modifying them. Your originals remain exactly as they came off the card.

Do not reorganize your folders. FrameQuery references files by their current location. If you move files after processing, the links break. Pick a folder structure, stick with it, and let FrameQuery handle the searchability layer on top.

Start with your most-used drives. If you have 80 TB of archived footage, do not try to process it all in the first week. Start with the drives and projects you actively pull from, and expand from there.

Use the source folder feature. FrameQuery's source folder monitoring can detect new files added to watched directories. When new footage lands on your archive drive, it shows up for processing automatically.

---

Your cinema footage deserves better than sitting unsearchable on a drive. Join the waitlist to try native R3D and BRAW search with your own footage.