Multi-camera video capture synchronization for four cameras

Four cameras that do not start together record four different scenes. A guided robot reaches for a part that has already moved, a stereo pair disagrees on depth, and every saved frame set carries an offset you cannot remove afterwards. Two numbers decide the fix: the inter-camera skew your application tolerates, and the bandwidth four simultaneous streams put on the host. Software-started capture drifts by milliseconds to tens of milliseconds; a shared hardware trigger or a PTP-scheduled exposure start holds skew to microseconds. This guide sets the skew budget, compares the three synchronization methods, works the bandwidth arithmetic for four 4 MP cameras, and lands on the host adapter that keeps all four streams flowing.

What the skew budget demands

Define synchronization as a single number: the skew between the first and the last camera to start an exposure for the same frame. Two checks set the budget.

The motion check. A part moving at 0.5 m/s travels 0.5 m/s × 0.010 s = 5 mm during a 10 ms software-start skew, enough to break stereo matching, four-view stitching and any cross-camera measurement. The same part under a 2 µs hardware-trigger skew moves 0.5 m/s × 0.000002 s = 1 µm, under a third of the 3-4 µm pixels common on area scan cameras, so the views still agree pixel for pixel.

The exposure check. Hold skew below roughly 1 percent of the exposure time. At a 1 ms exposure that is 10 µs, and only a shared trigger edge or a scheduled start reaches it. Software starts cannot: each command passes through the operating system scheduler, whose default desktop timer resolution sits near 15.6 ms, before the network stack adds its own delay.

The trigger edge starts the exposure; the exposure length is a separate setting that runs afterwards. Trigger call versus exposure time works through that timing, and it is why synchronizing the edge is enough even when the four cameras run different exposure lengths.

Three ways to put four cameras on one clock

One pulse source, scheduled starts or frame grabber timing — pick by wiring tolerance and camera interface.

Shared hardware trigger. A photoelectric sensor, a PLC output or a timing card drives one pulse to all four cameras' opto-isolated trigger inputs. Identical camera models start within a few microseconds of the same edge, and cable propagation adds roughly 5 ns per metre, so a 10 m length difference between lines costs 50 ns. Keep all four heads the same model; mixed sensor generations can differ by far more than the budget.

This is the pattern behind multi-camera exposure synchronization with a shared trigger, and it is the default for moving parts and strobed light. All four inputs need a common ground reference or the pulses never arrive — the failure the camera trigger common reference article diagnoses.

PTP-scheduled exposure starts. Cameras that implement the GigE Vision precision time protocol discipline their clocks over the network and begin each exposure at a programmed instant, with no trigger cable at all. On a dedicated switch, clock alignment lands sub-microsecond and start jitter stays microsecond-class. It is the clean answer when the cameras already share one switch and the mechanics cannot take another cable.

Frame grabber timing. CoaXPress and Camera Link frame grabbers generate the trigger pulses in hardware with programmable offsets per port, which is what sequenced rigs need: exposures offset by fixed microseconds or milliseconds, or triggers slaved to an encoder.

Worked example: four 4 MP cameras at 30 fps on one host

The case: four 4 MP sensors captured simultaneously, uncompressed. Inputs: 4,000,000 pixels per frame, 8-bit mono output at 1 byte per pixel, 30 frames per second per camera, and line rates set by the Ethernet standards — 1,000 Mb/s GigE, 2,500 Mb/s 2.5G, 10,000 Mb/s 10GigE. The assumption: with jumbo frames on a dedicated port, about 90 percent of the line rate arrives as image payload.

The rule: data rate per camera = pixels × bytes per pixel × frame rate, and a port only stays usable while the per-camera rate remains inside that usable payload.

Read the arithmetic as a decision. One 4 MP camera at 30 fps already saturates a GigE port at 107 percent, so the one-camera-per-GigE-port layout works only at or below about 28 fps per camera. At 30 fps, give each camera a 2.5G port at 43 percent load; at 60 fps the same frame runs at 86 percent of a 2.5G port, so move to 10GigE, where one port can even carry all four cameras (480 MB/s against 1,125 MB/s usable, 43 percent). The host must take 480 MB/s of sustained ingress, and a recording disk has to sustain the same figure, which means NVMe or a striped array rather than a single spinning drive.

The same arithmetic sizes the buffers: one second of margin for one camera is 4 MB × 30 = 120 MB, so four to eight buffers per camera (16-32 MB) ride out only a fraction of a second of stall. Longer stalls are a recorder problem, not a buffer problem.

Picking the host adapter and the host machine

Host-side bandwidth, not camera count, picks the hardware.

Dedicated GigE ports, one camera each. The layout that works while every camera stays at or below about 28 fps at this frame size. Frame grabbers with independent ports keep each stream on its own controller, and assigning cameras to ports reliably keeps that mapping stable across reboots.

2.5G ports at 30 fps. Four independent 2.5GigE ports put each camera of the example at a 43 percent load, with room for bursty moments.

10GigE when the rate or the bit depth grows. A single 10GigE port can carry all four cameras at 43 percent load, which leaves headroom for 12-bit output or 60 fps later.

PoE on smaller benches. Power over Ethernet feeds the cameras over the data cable itself, which removes four camera power supplies from a compact rig.

CoaXPress heads. CXP cameras take both their stream and their trigger timing from a frame grabber in the host:

The machine around the card. Ingesting 480 MB/s while processing and firing strobes is what purpose-built hosts are for. A vision controller bundles the network ports, memory and light channels in one chassis, keeping capture and strobe timing in the same box.

The MV-VC3301H-128G66 in that role pairs five-plus LAN ports with four built-in light channels. When the four streams arrive faster than the software digests them, acquisition faster than processing: fix the frame rate gap shows how to find the stage that lags. For the wider host picture — CPU, memory, storage and interface selection for multi-camera rigs — this multi-camera embedded video hardware selection guide goes deeper.

Software settings that keep four streams alive

Trigger on, one-shot off: set each camera to acquire continuously while accepting the external trigger. The camera that takes one frame and then ignores every later pulse is stuck in single-shot acquisition mode, and hardware trigger stops after one frame is the fix.

Then three habits hold a four-camera stream together.

One wait per frame, per camera. Four cameras mean four independent receive loops; a loop without a timeout, or one wait shared across cameras, stalls the whole set. The mechanics are in frame didn't arrive within timeout.

Buffers sized to the stall you must survive. From the example arithmetic, 4 MB frames mean that four to eight buffers per camera absorb only a fraction of a second. Beyond that the recorder has to keep pace, which is the subject of multi-camera recording to disk without dropped frames.

Staggered starts. A programmable trigger delay of about 1 ms per camera shifts each camera's transfer window, so four 120 MB/s streams do not land on the host in the same millisecond — without changing what the scene shows.

Prove it on the bench before trusting timestamps: fire one short flash or drop a marker into view, and every camera must catch it at the same frame index. If frames still drop on GigE, the network-side causes — switch buffers, jumbo frames, interrupt load — are worked through in this frame-drop troubleshooting guide for multi-camera GigE systems.

When the usual answer is wrong

Four cases where the shared trigger is the wrong tool.

Static scenes and analytics. If nothing in view changes meaningfully within tens of milliseconds — occupancy counting, presence detection — software timestamps are honest enough, and the trigger wiring buys nothing.

Phase-shifted capture. Structured-light 3D and multi-light sequences want exposures at controlled offsets, not the same instant. Program a per-camera trigger delay instead of fanning one pulse to all four.

Line scan. A line scan rig follows an encoder continuously, so one-shot trigger logic does not describe it; driving a linear image sensor with a DAQ card clock and trigger covers that clocking pattern.

Cameras on separate hosts. One pulse cannot cross two PCs. Synchronize each host's cameras with its own shared trigger, then tie the hosts together with PTP or a common strobe, as in multi-host camera synchronization with a shared LED strobe.

Before you order: the pre-flight checks

• Frame budget. Pixels × bytes per pixel × fps per camera, summed across the set: the example rig costs 480 MB/s of continuous ingress.
• Port budget. Per-camera rate inside the usable payload: about 28 fps per camera on GigE, 70 on 2.5G, 280 on 10GigE for a 4 MB frame.
• No shared hops. One camera per port; if a switch sits in the path, its uplink must carry the summed rate.
• Trigger drive. The pulse source supplies all four inputs within their voltage and current ratings, and every input references a common ground.
• Strobe window. The light channels fire inside every camera's exposure, which means inside the shortest exposure of the set.
• Bench proof. One flash, the same frame index on all four heads, timestamps logged before the rig ships.
• Recorder headroom. A recording disk sustains the full 480 MB/s, not an average of it.

Two multiplications and one port comparison decide a four-camera capture rig. Shortlist the heads in the camera finder, work the arithmetic above, then let the build-a-system configurator pair the cameras with an adapter, a controller and light channels; the rest of the timing guides sit on the systems topic page. For a configured four-camera set, request a quote.