High speed camera recording without dropped frames

A camera can acquire a short burst correctly while the recording application loses frames during conversion, compression or file writing. A video that plays smoothly is not proof that every exposure was saved. For engineers recording fast events, the reliable approach is to measure acquisition separately, retain frames in a bounded memory buffer, and record through a dedicated worker. You will define the burst, calculate its memory requirements, select a recording format, and verify completeness using frame identifiers and timestamps.

Define what a complete recording means

Specify the recording contract before selecting a codec. Record the camera count, image dimensions, pixel format, target acquisition rate and burst duration. Also define whether the requirement concerns delivered images, externally triggered exposures or synchronized observations across cameras.

These are different quantities:

Assigning a playback rate does not configure the camera. Likewise, choosing a short exposure does not necessarily establish the requested acquisition rate.

For exposure, pixel-format and bandwidth constraints, use the related camera frame-rate limits guide. Keep those camera-side limits separate from recording performance.

Define failure explicitly: a missing image, an incomplete transfer, a duplicated frame identifier or an unreported queue overflow should invalidate a recording that promises complete capture.

Calculate the raw data budget first

Use the payload delivered by the acquisition interface, not a compressed image size measured afterward. Packed formats, row padding and metadata can change the payload, so confirm the actual buffer size reported by the SDK.

For an unpadded, unpacked image, the starting estimate is:

Consider a hypothetical burst from two cameras, each delivering 640 × 480 images at 160 fps for 2 seconds. Assume Mono8 or Bayer8 delivery, with one byte per pixel and no padding.

That is about 98.3 MB/s of image payload and 187.5 MiB for the complete burst. Here, MB means 1,000,000 bytes; MiB means 1,048,576 bytes.

Adding an illustrative 25% payload reserve gives 245,760,000 bytes. This is not the total application memory requirement: SDK buffers, alignment, conversion buffers and operating-system needs remain additional.

Converting every input image to RGB8 triples the unpadded image payload in this example, raising it to approximately 295 MB/s. Retaining Bayer8 data until after capture can avoid that immediate expansion, provided you preserve the pixel-format and Bayer-pattern metadata.

Configure and benchmark acquisition without recording

Use the current manufacturer-supported SDK and its documented acquisition examples. Obtain software and documentation from the manufacturer or its authorized distributors, rather than adapting an obsolete or unofficial API example.

Follow this setup sequence:

1. Open each camera and stop acquisition before changing features that require an idle device.
2. Set image width, height and offsets within the device's documented increments and limits. Read the accepted values back.
3. Select the delivered pixel format explicitly. Do not assume the preview format matches the acquisition payload.
4. Configure free-running acquisition or the required trigger mode. Set a frame-rate limit only where supported and applicable.
5. Set exposure with margin for the required timing. Check the camera's readout and overlap restrictions rather than assigning exposure equal to the nominal frame interval.
6. Allocate acquisition buffers, start receiving, and measure complete images without encoding or disk writes.

At the example rate, the nominal frame interval is 1 / 160 = 0.00625 seconds, or 6.25 ms. Confirm the measured interval using camera timestamps where available.

For external pulses, follow the hardware-trigger frame-rate checks. If settings change during application startup, the trigger-overlap configuration guide explains why readback matters.

Run this baseline with all intended cameras active. If frames already disappear, investigate transport, buffer handling or acquisition configuration before changing the recording format.

Separate acquisition from the recording worker

The acquisition path should receive, validate, transfer ownership and return promptly. It should not compress images, update a full-resolution preview or wait for disk access.

A practical ownership sequence is:

1. Receive a completed SDK buffer and check its status.
2. Obtain a free application-owned slot from a preallocated pool.
3. Copy the payload and metadata into that slot, then release the SDK buffer promptly.
4. Put the slot identifier into a bounded recording queue.
5. Let the recording worker write the frame and return the slot to the pool only after it no longer needs the data.

A documented SDK buffer-ownership transfer can replace the copy, but only when its lifetime rules are understood. Keeping references to reusable acquisition memory can silently record later images under earlier identifiers.

Attach camera identity, frame identifier, camera timestamp, host receive timestamp, dimensions, pixel format and payload length to each queued frame. Multiple workers must preserve per-camera ordering or store enough metadata to reconstruct it.

Make queue exhaustion an explicit recording failure. Blocking the receive path can shift the overflow into the SDK or transport layer; silently discarding an old frame hides the failure instead.

The multi-camera callback and buffer-queue guide covers ownership problems that can resemble recording faults. The acquisition-session architecture guide helps separate per-camera state from shared workers.

Size the queue for the burst, not average optimism

A bounded queue limits memory consumption, but its capacity must match the recording strategy. Decide between storing the entire burst before writing and writing concurrently while retaining enough buffering for temporary slowdowns.

For the worked example, a queue holding 32 frames across both cameras represents:

That queue absorbs only a short interruption. It cannot compensate for a worker that remains slower than the incoming stream.

Suppose the complete recording worker sustains 64 MB/s against the calculated input of 98.304 MB/s. Ignoring startup effects:

The small queue would fill before the burst ended. A full-burst memory pool can instead hold every image while encoding and storage finish afterward.

Measure the whole writer path: conversion, compression, metadata handling, file creation and storage. A drive-only benchmark excludes several common bottlenecks. Short writes may also be absorbed by operating-system caching, making application write speed look better than sustained storage performance.

For short, infrequent events, capture-then-encode is often the simplest design. Continuous recording requires sustainable throughput or a deliberate reduction in data rate; a larger finite queue only postpones failure.

Choose the recording format by its purpose

Separate the acquisition format from the archive or viewing format. Preserve original samples when later measurements depend on exact pixel values.

A container such as Matroska or MP4 does not determine image fidelity by itself. The codec, pixel format, conversion path and encoding settings determine what happens to the samples.

PNG compression can be expensive even when the output is smaller than raw data. JPEG typically introduces loss. Neither format automatically makes a high-rate acquisition loop fast enough.

If an encoder requires color conversion, establish whether that conversion belongs during capture or after it. Do not label a converted stream as identical to the original sensor samples merely because the codec is lossless.

For a short burst, retain the acquisition payload first and produce a convenient playback copy afterward. Keep original timing metadata alongside any constant-rate viewing copy.

Verify counts, timing and saved content

Maintain separate counters for successful receives, accepted queue entries, completed writes and validated stored frames. Count failures and rejected entries separately rather than hiding them inside an average rate.

For the example, expect 320 frames per camera and 640 combined. Check each camera independently; a correct combined total can conceal missing frames from one stream and extras from another.

Use the SDK's documented frame-identifier semantics when checking gaps. Identifier increments, resets and wraparound behavior are device-specific. Where available, compare delivered frames with camera-side or trigger counters; host receive counts alone cannot prove every requested exposure occurred.

Camera timestamps help reveal acquisition spacing. Host monotonic timestamps reveal delivery pauses and queue delays. Do not subtract timestamps from different camera clocks as if they share an origin unless synchronization has been established.

After acquisition stops, drain the queue, finalize the recording, close it and reopen it for validation. Decode every video frame or enumerate and read every image. For a lossless archive, compare reconstructed pixel samples with the saved source data or suitable checksums.

If delivery fails even with recording disabled, use the acquisition-stall isolation procedure before investigating codecs.

Check camera, cable and controller suitability before ordering

Select area scan cameras against the required image dimensions, delivered format and achievable acquisition rate. The camera finder helps narrow the interface and sensor choices, but a resolution specification alone does not establish burst performance.

The LS-CMR-0053 is a 12 MP GigE camera with a listed frame rate of 9 fps.

The LS-CMR-0166 is a 12 MP USB3 camera with a listed frame rate of 30 fps.

These are interface examples, not selections for the worked burst. Their listed specifications do not establish the required reduced-region performance; obtain confirmation for the intended operating mode.

Check camera cables for interface, connector, retention and installation requirements through the accessories finder.

The LS-CBL-0218 is a 5 m USB3.0 camera cable.

Confirm connector compatibility before selecting it. Cable length alone does not establish suitability for a particular camera or moving installation.

When comparing vision controllers, check memory capacity, independent camera connections and measured recording performance. Port count alone does not establish aggregate throughput or encoder capacity. Keep acquisition buffers and recording memory in the controller's capacity calculation.

Qualification checklist and next step

Before accepting the recorder, complete these checks:

• Read back settings: confirm dimensions, format, exposure and trigger configuration after the application starts.
• Repeat the acquisition-only baseline: all intended cameras must deliver the required burst without recording enabled.
• Measure queue high-water level: retain margin for writer stalls rather than relying only on average throughput.
• Exercise the intended storage path: include the real filesystem, metadata, codec and expected free-space conditions.
• Test repeated bursts: include draining, file finalization and rearming in the required cycle time.
• Validate saved data: compare per-camera counts, identifier continuity, timing and decoded content.
• Report failures visibly: never mark an overflowed or incomplete burst as successful.

Full-burst buffering is the wrong answer when recordings are continuous, available memory is insufficient, or bursts arrive before the previous backlog drains. Those cases require sustainable processing and storage throughput, a lower acquisition payload, or a revised recording requirement.

Start with the camera configuration step when the acquisition requirements are settled. For a recording-path review, contact the applications team with the payload format, camera count, target rate, burst duration and measured writer throughput.