Multi-camera BRAW planning is not a single-camera estimate multiplied at the end. Every additional camera increases total storage, but it also changes card turnover, simultaneous offloads, destination throughput, labeling, synchronization, proxy demand, and the number of failure points the data team must manage.
The arithmetic starts with multiplication. The reliable workflow starts with a camera-by-camera schedule.
Calculate each camera separately
Do not assume every camera records the same format or amount. A common event package might use:
- Camera A: 6K 5:1 for primary coverage
- Camera B: 6K 8:1 on a long lens
- Camera C: 4K 8:1 locked wide
- Camera D: 4K 12:1 for safety coverage
Estimate resolution, capture fps, compression, and recorded hours for each camera. Add the results only after each has its own base number.
This preserves useful decisions. If storage must be reduced, the team can see which camera contributes the most data and whether that camera actually needs the current mode.
Example: three-camera interview day
Assume the following approximate base rates at 24fps:
- Camera A: 6K 5:1 at 156.7MB/s
- Camera B: 6K 8:1 at 97.9MB/s
- Camera C: 4K DCI 8:1 at 40.8MB/s
If all three record two hours:
- Camera A: about 1.13TB
- Camera B: about 0.70TB
- Camera C: about 0.29TB
- Base total: about 2.13TB
With a 20% production buffer, allocate roughly 2.55TB for camera originals. Two verified destination copies require about 5.10TB of free capacity. Add audio, stills, project files, proxies, and drive headroom, and two 4TB working drives becomes more realistic than two nearly full 3TB volumes.
The BRAW calculator can produce the per-camera values. A spreadsheet or call sheet can hold the aggregate schedule.
Simultaneous recording creates an ingest wave
Three cameras can fill three cards at nearly the same time. Total daily capacity may be adequate while the data station is overwhelmed during breaks or card changes.
Model the worst handoff window:
- How many cards can arrive together?
- How full is each card expected to be?
- How many readers can operate without sharing a slow hub?
- Can the destination sustain simultaneous writes?
- Are copies made sequentially or to two destinations at once?
- How long does verification add?
- When must the cards return to camera?
If three 512GB cards arrive together, the station may need to process more than 1.5TB before the next turnover. A single fast reader cannot fix a destination that writes slowly under concurrent load.
Card pools need individual camera IDs
Use unique identifiers that cannot collide:
- A001, A002, A003 for Camera A
- B001, B002, B003 for Camera B
- C001, C002, C003 for Camera C
Physical labels, camera reel metadata, folder names, and reports should agree. Do not reuse a card ID until the production has a clear reset policy, and do not rely on camera-generated filenames as the only unique key.
The log should record checkout, return, copy status, verification, and release. A “green” physical state must mean the same thing to camera and data teams.
Keep camera settings visible
Multi-camera shoots often drift when one body changes frame rate, sensor window, or compression for a special shot. That change can double a card’s data use and break the offload assumption.
Record mode changes in the camera report and communicate them before the card arrives. If a camera switches to Constant Quality or high frame rate, the data team should update both the capacity forecast and the reader schedule.
Storage throughput for multicam editing
Aggregate acquisition volume is only one issue. Multicam editing can request several BRAW streams at once.
Add the active streams:
Required source throughput ≈ sum of each active stream’s MB/s
Four 100MB/s angles imply about 400MB/s before audio, caching, effects, and operating-system work. The computer must also decode four RAW streams. Even a fast SSD cannot solve a CPU/GPU decode limit.
Proxies can reduce both problems. Create consistent proxy resolution, codec, frame rate, timecode, and filenames so the NLE can relink without manual repair.
Backup design
A minimum on-set goal is two verified copies on separate physical devices before source cards are released. For irreplaceable material, productions often keep a third copy or send one copy to a separate location.
Avoid these false redundancies:
- Two folders on the same drive
- Two partitions on one device
- A RAID treated automatically as a backup
- Source media plus one destination when the source must return to camera
- Two devices transported in the same unprotected bag
Verification should use checksums or a trusted copy tool, not only file counts. Spot playback is useful but does not verify every byte.
Optimize without weakening every camera
If the plan is too large, adjust by role:
- Lower the locked wide camera’s resolution if reframing is unnecessary.
- Use a more efficient ratio on a clean, low-priority safety angle after testing.
- Keep higher quality on the hero or VFX camera.
- Limit high frame rate to planned takes rather than leaving it enabled.
- Reduce overshooting through clear roll discipline.
- Add offload capacity instead of compressing critical footage solely to fit an inadequate station.
The goal is not identical settings. The goal is a consistent rationale that post understands.
A complete multicam planning sheet
For each camera, include:
- Body and operator
- Sensor window and pixel dimensions
- Project fps and capture fps
- BRAW mode
- Estimated MB/s
- Card capacity and planned reserve
- Minutes per card
- Number of cards in rotation
- Estimated recorded hours
- Base and buffered storage
- Proxy requirement
- Timecode and audio strategy
For the production, include:
- Peak simultaneous ingest volume
- Reader count and interface layout
- Destination sustained write rate
- Copy-and-verify time per card
- Primary, secondary, and shuttle drive IDs
- Daily archive or transfer deadline
- Person authorized to release source media
Multi-camera storage becomes manageable when each stream is visible and every card has a state. The math prevents a capacity shortage; the process prevents a footage loss.
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.
Use the BRAW storage and recording-time calculator to model your exact resolution, frame rate, compression setting, safety buffer, and media capacity.