Multi-camera recording to disk without dropped frames

Recording four or more machine-vision cameras continuously sounds simple until the first dropped frame appears an hour into a test. The cause may be an architecture that asked one link, one buffer pool or one disk to carry more than it could. This guide is for engineers building multi-camera recording rigs for long tests, such as structural or endurance trials, where every frame matters. You will learn how to compute the aggregate bandwidth, choose between memory-first and disk-first capture, plan cable runs to cameras tens of metres away, and verify the design before a single frame is recorded.

Why multi-camera rigs drop frames

A single-camera pipeline has three stages: the camera pushes frames over its link, the driver delivers them into host buffers, and the application writes them out. Each stage has a fixed capacity. In a multi-camera rig, several stages may be shared, so the weakest shared stage sets the ceiling for all cameras together.

The typical failure pattern looks like this: each camera alone records perfectly, so the system passes bench testing. With four cameras running, the aggregate rate approaches the disk's sustained write speed. Writes begin to queue, available buffers run out, and acquisition starts losing frames. You see it as regular small gaps, often on all cameras at once.

The fix is to know your aggregate number before you buy anything, and to keep every stage comfortably above it.

Do the bandwidth math first

For uncompressed images, calculate the payload rate from the actual stored frame size. Account separately for transport overhead, metadata and any format conversion:

Worked example: four mono 8-bit cameras at 1280 x 720 and 30 fps. These calculations use decimal MB and GB.

• Per camera: 1280 x 720 x 1 x 30 = 27.648 MB/s
• Aggregate: 4 x 27.648 = 110.592 MB/s, or about 111 MB/s
• Per hour: 110.592 x 3600 / 1000 = about 398 GB
• A two-hour test needs about 796 GB of written image data, before any headroom

Now compare that aggregate with your storage. Do not assume a drive or array's sustained performance from its interface or drive count. Benchmark the intended recording workload across the capacity you expect to use. A striped array can increase throughput, but RAID 0 provides no redundancy: one drive failure can lose the recording. As a conservative starting point, reserve about 20 percent of storage capacity and keep the aggregate rate below 60 percent of measured worst-case sustained write speed.

Watch the link side too. One GigE link may deliver around 110 MB/s of image payload under suitable conditions. Several cameras from this example can therefore share a sufficiently provisioned link, but all four would leave effectively no margin. Higher-resolution cameras change the picture dramatically. The LS-CMR-0166 has a USB3 interface, 30 fps and 4000 × 3000 resolution. At that image size and rate, an uncompressed mono 8-bit payload is 4000 x 3000 x 1 x 30 = 360 MB/s. Check the USB path and storage separately; a USB3 camera does not become a network camera because its data rate increases.

Memory-first versus disk-first architectures

The first question to answer is: for how long? The answer decides your whole architecture.

Short tests: record to RAM. If the entire capture fits in available memory, disk never enters the real-time path. At 111 MB/s, a dedicated 32 GB capture allocation holds about 4.8 minutes; 64 GB holds under ten. Installed memory must also accommodate the operating system, application and other buffers. Acquisition runs into pre-allocated buffers at full speed, and a file write happens afterwards. This removes storage stalls during acquisition, but its limit is hard arithmetic, not tuning.

Long tests: stream to a disk array. For minutes to hours, continuous writing is unavoidable. Use a ring of large pre-allocated buffers per camera, dedicated writer threads, and storage fast enough that the writers keep up on average. RAM absorbs jitter; storage handles the average. If RAM ever fills, frames drop, so sustained write speed, not burst speed, is your design number. Benchmark both shared and per-camera writer arrangements rather than assuming more threads improve throughput.

Buffer sizing matters more than buffer count. A camera delivering 27.6 MB/s with 1000 ms of buffering needs about 28 MB of buffers; give each camera two to four seconds' worth as an initial allowance for brief disk stalls. Measure the actual stall duration before accepting that allowance. When stalls propagate, check callback duration and buffer ownership. Our article on camera frame conversion hangs and buffer ownership covers a related failure mode in acquisition pipelines.

Network and cabling for cameras metres apart

Cameras spread across a test article or a test cell change the network design. The rules that matter:

• Prefer one dedicated link per camera. Shared switches are possible, but their uplinks, switching capacity and packet buffering must support the simultaneous traffic.
• Copper GigE supports channels up to 100 m with suitable cabling, so a 30 m run is within reach. Test the installed channel with a cable certifier, not just by whether the link comes up.
• Above GigE, verify the physical interface and cable rating. Suitable 10GBASE-T channels can reach 100 m; other copper interfaces have different limits. Compatible fibre equipment is another option where distance or electrical isolation requires it.
• Keep PoE budgets in mind. If the card powers the cameras, its per-port and total power budgets limit what it can feed.

The MV-GE2002P is a dual-port PoE NIC. The MV-GE1104 is a 4-port GigE frame grabber. When cameras are 30 m apart, a suitable switch near each cluster is an option only if the uplink and switching capacity support the cluster's aggregate traffic with margin. Otherwise, run each camera all the way back.

Choosing the recorder hardware

Think of the recorder as three budgets: link bandwidth, PCIe and memory bandwidth, and disk write bandwidth. All three must clear the aggregate figure.

For four to eight GigE cameras, a multi-port network interface is a common approach. Above that, or at higher rates, check the card's host interface and aggregate throughput rather than counting ports alone. The MV-GT2104 is a quad-port copper 10GbE NIC. For CoaXPress acquisition, the MV-GX1008 is an Octo CXP-6 frame grabber. Camera interface compatibility remains a separate requirement from total bandwidth.

The host machine is the part most often undersized. You need enough RAM for several seconds of buffering per camera, a CPU that is not saturated by copy loops, and sufficient PCIe connectivity for the capture cards and storage. The MV-VC5525-256G70-NN lists 32 GB of memory, PoE camera ports and 8 built-in channels for light outputs. Those features do not establish recording throughput; verify expansion compatibility and sustained performance for your workload. Start at the vision controllers category, or use the system configurator to begin with your camera requirements.

The camera side matters mainly through its data rate and interface; browse the area scan cameras category and filter by interface and resolution. For deeper background on keeping a single stream healthy, the guide on finding a camera frame-rate bottleneck covers acquisition limits. The article on camera acquisition backend compatibility helps separate software integration problems from hardware capacity limits.

Worked example: four cameras, two hours, 30 m spans

Specification: four mono cameras, 1280 x 720, 30 fps, GigE, two cameras 30 m from the recorder, capture two hours with no dropped frames.

1. Aggregate rate: about 111 MB/s, as computed above.
2. Links: four dedicated GigE ports, one per camera; the 30 m runs are within the supported channel length when correctly installed. The MV-GE1104 is a 4-port GigE frame grabber. Verify its host connection and software support before selecting it for the rig.

3. Buffers: 4 s per camera at 27.6 MB/s means about 110 MB per camera, 440 MB total. A 2 GB capture allocation provides additional margin on a host with sufficient memory remaining for software and the operating system.
4. Storage: two hours produces about 796 GB of image data. Keeping that below 80 percent of usable capacity requires about 995 GB before filesystem and metadata allowances. A measured sustained write rate above 185 MB/s satisfies the proposed 60 percent loading limit; storage sustaining above 300 MB/s provides more margin.
5. Verification: run the full duration with no part present, log every camera's frame counter, and confirm zero gaps before the first real test. Also verify that every accepted frame reaches a readable file.

For a real sensor reference point, the LS-CMR-0166 lists 30 fps at 4000 × 3000 resolution over USB3. Four streams at that image size and rate would produce 1.44 GB/s of uncompressed mono 8-bit payload. Such a configuration needs sufficient independent USB host bandwidth, memory throughput and sustained storage performance. It does not require changing the cameras to a network interface; this is why the bandwidth table comes first and the parts list second.

Synchronization: decide before you order

Pure recording does not necessarily require synchronized cameras; each stream can be stored independently. Verify which timestamps and frame identifiers the acquisition system provides. Three common follow-on needs require a deliberate timing design:

• Comparing events across cameras requires a known relationship between exposure times, typically through a shared trigger or supported common-clock synchronization.
• Combining views geometrically for measurements of moving objects requires exposures aligned closely enough for the permitted motion error.
• Correlating with test-rig data such as load cells requires timestamping against one reference clock or measuring the offset between clocks.

Adding triggering later means new cabling, suitable trigger distribution and possibly different cameras. If any cross-camera analysis is likely, specify the allowable timing error and a supported synchronization method now. The article on aligning sensor events with camera exposure explains the timing distinction. For software identity and connection management, see assigning cameras to ports reliably.

Checks before you commit

Run this list against any proposed rig:

• Aggregate rate computed from actual frame sizes and stored pixel formats, not marketing figures.
• Worst-case sustained disk write speed at least 1.67x the aggregate for the proposed 60 percent loading limit.
• Dedicated links per camera, or shared links validated for aggregate traffic and synchronized bursts.
• Buffer allocation of at least 2 s per camera as a starting point, pre-allocated at startup and checked against measured stalls.
• Cable runs certified, especially anything over 20 m.
• Capture at full duration with frame counters and file completeness checked before the first real test.
• Writer threads decoupled from acquisition callbacks.

Include simultaneous startup and restart in the test plan. The guide on camera discovery startup contention addresses a separate multi-camera problem that a storage benchmark alone will not reveal.

When the usual answer is wrong

The standard advice is "add bandwidth and buffers", and often that is right. Three cases need a different investigation:

• The drop is periodic at the same frame count. Check fixed-size buffers, file rotation and periodic software tasks. Repeat at a different frame rate to distinguish frame-count effects from elapsed-time effects.
• Drops appear only on some cameras. Isolate each affected camera on a separate port and re-run. Check its cable, port, configuration and processing path before blaming aggregate bandwidth.
• Frames arrive but are corrupt. Inspect acquisition status and transport error counters, then compare the received buffer with the saved image. Cable faults can cause incomplete transfers, but incorrect stride, pixel format or buffer ownership can also corrupt images. Use vendor-documented retransmission settings where supported; they do not replace fixing a faulty link.

Checklist

Before ordering:

1. Compute the aggregate data rate from width, height, stored bytes per pixel and frame rate.
2. Choose storage with at least 1.67x that rate in measured sustained writes for the proposed loading limit.
3. Assign one network port per camera, or validate shared-link capacity; plan cable certification for runs over 20 m.
4. Size RAM for several seconds of buffering per camera and the longest measured storage stall.
5. Decide now whether cross-camera analysis needs shared triggering or common-clock synchronization.

Before the first test:

6. Run a full-duration blank capture with frame counters logged on every camera.
7. Confirm zero drops, zero corrupt frames and matching received-versus-written frame counts.
8. Note the storage write speed during the run; if it trends downward as capacity fills, increase your margin or change the storage design.

If you want the pieces chosen for your camera list and test duration, send the numbers through the quote request or contact the applications team. Include the pixel format, frame rate, duration, cable lengths and synchronization requirement so the complete acquisition path can be checked.