Every capture passes through several stages before the result is ready: files are transferred from the cameras or nodes, datasets are prepared, processing tasks run, outputs are rendered, and the result is written for review or delivery. Optimize the slowest stage instead of changing several settings at once.

1. Direct camera and USB hub architecture

For a rig with several cameras connected to one Windows computer:

Hardware

• Use a fast computer with a modern multi-core processor and a fast local SSD.
• Connect the computer to a high-quality USB-C or USB 3 controller or hub.
• Avoid chaining USB hubs. Keep the topology simple and distribute cameras across independent controllers when the rig is large.
• Use short, reliable USB cables and test every hub port under a real capture load.
• Keep the active working directory on a local SSD. Do not place it inside OneDrive, Google Drive, or another cloud-sync folder.

Camera and output settings

• Use the smallest camera resolution that meets the final output requirement. Larger files increase transfer time, storage use, processing time, and output time.
• Configure only the processing tasks and output formats that the event actually needs. Disable unnecessary renders, previews, or delivery outputs while testing throughput.
• Start with a moderate output quality and a fast codec preset, then increase quality only when the visual result requires it.
• Test the complete path with a representative dataset. A small single-camera test does not reveal the transfer and processing limits of a full rig.

2. Raspberry Pi architecture

Raspberry Pi camera nodes can distribute capture and transfer work across the network. This can improve triggering and throughput, especially when a Windows computer would otherwise handle too many camera connections through USB.

• Use a Gigabit Ethernet switch for the nodes and the Camera Server computer.
• Avoid daisy-chaining switches. Use a simple star topology where possible.
• Confirm that the computer and each node negotiate a 1000 Mbps link, not 100 Mbps.
• Use reliable Ethernet cables and dedicated network infrastructure for the rig instead of sharing a congested event or office network.
• Add nodes when the measured transfer or capture workload requires it. More nodes also mean more power, cabling, and network dependencies, so test the complete system after each change.
• For RAW or high-resolution workflows, expect file transfer and storage to become the limiting stages even when triggering remains responsive.

3. Find the slow stage

Measure the same representative capture several times and identify where the delay appears:

1. Capture and transfer: cameras or nodes take too long to finish sending files.
2. Dataset preparation: files arrive, but analysis or organization is slow.
3. Processing: an enabled process task consumes most of the time.
4. Rendering and output: resizing, codec work, watermarking, or other output tasks are slow.
5. Storage or delivery: the destination drive, network, or backup path has low throughput.

Watch CPU, memory, GPU, disk activity, disk throughput, and network throughput while the job runs. High disk activity with very low throughput points to a storage bottleneck, not necessarily a CPU problem. Check Known issues for the SSD write-bottleneck symptoms.

Change one variable at a time, record the result, and keep the settings that improve the full event workflow rather than only one isolated stage. Always run a complete multi-camera test before relying on a faster configuration at an event.