Camera buffer timestamp latency: interpret frame timing

A successful camera buffer can contain an image whose timestamp precedes your dequeue call by almost one frame period. That does not, by itself, mean the application received the previous image. The timestamp may describe exposure, the first received packet, or another event that necessarily happens before the complete image becomes available. For continuous-acquisition systems, the useful test is to identify that event, compare timestamps within a known clock domain, and measure where the elapsed time accumulates.

First decide whether the image is old or merely takes time to arrive

A successful buffer status generally means the acquisition library accepted the buffer as a completed image without a reported acquisition error. Check the library's exact definition. Success does not establish that the image was exposed after your latest function call, nor that its timestamp represents completion.

In continuous acquisition, the camera produces frames independently of when your application requests a completed buffer. Providing an empty receive buffer makes storage available; it does not usually request a fresh exposure. Dequeuing retrieves an available completed buffer according to the library's documented queue behavior.

Distinguish these three conditions:

• Expected delivery time: the timestamp marks an early event, and the application retrieves the image promptly after completion.
• Application backlog: completed images wait while processing, logging, or display work occupies the consumer.
• Frame-association error: the application compares an image with a trigger, result, or timestamp belonging to another frame.

For irregular arrival spacing, use the companion guide to separating camera timing from GigE Vision frame arrival jitter. Arrival variation and consistently delayed timestamps require different tests.

Identify both the timestamp event and its clock

A timestamp is useful only when you know what event it marks and which clock produced it. A field described as a system timestamp is not automatically the time when the image became ready for processing.

For some streaming libraries, a buffer's host timestamp marks receipt of the first data packet. Other implementations use different events. Read the documentation for the installed version rather than transferring assumptions between libraries.

A host wall clock and a host monotonic clock are different clock domains. A camera clock is another domain unless a documented synchronization or mapping connects it to the host. Matching units does not make clocks comparable.

For elapsed host intervals, prefer a documented monotonic clock. If the library exposes a different clock, use its documented conversion or collect an independent, comparable timing trace.

Calculate the intervals that answer the question

Separate image transfer from completed-buffer waiting. Use timestamps from the same clock domain and define each event explicitly.

The post-completion interval can include queue residence, thread scheduling, notification handling, and application delay. Calling all of it network latency hides the distinction you need for diagnosis.

If the library does not expose completion timing, measure first-packet-to-dequeue time but keep it as a combined interval. Do not invent a completion timestamp from the start of a blocking dequeue call.

A frame period is not a universal delivery deadline. At 30 frames/s:

Transfer alone can consume a substantial fraction of that interval. Consider a hypothetical uncompressed monochrome image with one byte per pixel:

This is a payload-only estimate for a nominal gigabit link. Protocol overhead, packet spacing, resends, and receiver behavior can increase delivery time. Packed pixel formats, padding, and additional image metadata change the payload calculation.

At 30 frames/s, that example requires approximately 94.4 MB/s of image payload before overhead. Such a stream needs a careful bandwidth budget; a timestamp age near the frame period is not sufficient evidence of a stale frame.

Collect a trace without changing acquisition behavior

Start with the existing continuous-acquisition configuration. Avoid changing exposure, acquisition mode, packet size, and queue depth together, because you will lose the baseline.

1. Record the effective configuration. Capture exposure, frame rate, image dimensions, pixel format, trigger mode, and receive-buffer count. Record settings read back from the device, not only requested values.
2. Record frame identity. Log the documented frame or block identifier alongside every returned image. Handle identifier rollover according to the transport or library documentation.
3. Record available buffer metadata. Include status, camera timestamp, host timestamp, and their documented units and event definitions. Copy metadata before returning the buffer to the stream.
4. Timestamp dequeue return immediately. Use a lightweight monotonic-clock call before image conversion, disk access, inference, or display.
5. Record completion independently if available. A documented completion event or receive callback can help, but its execution time may include scheduling delay.
6. Capture a short sequence. For example, record 300 frames with display and synchronous file writing disabled. Store compact records and write them outside the acquisition-critical path.
7. Return buffers correctly. Follow the library's ownership rules, including error paths. Do not access image memory after requeuing it unless a documented ownership mechanism permits that access.

If processing continues asynchronously, retain the buffer through a supported mechanism or copy the required image and metadata before reuse. Otherwise, later access can observe overwritten memory and resemble a timing or frame-identity fault.

Use timestamped frame-rate measurement to check capture cadence. Application loop frequency is not a reliable substitute for the camera's frame sequence.

Read a worked trace before declaring one-frame lag

The following synthetic example uses a common host monotonic timebase. The exposure event is included only because this example assumes a separately validated camera-to-host clock mapping.

The measured intervals are:

At 30 frames/s, first-packet-to-dequeue time equals approximately one frame period. Nevertheless, the trace does not show a completed image waiting for an entire frame period. Most of the measured interval occurs before completion.

Now suppose the next frame is dequeued at 1066.6 ms, with its first packet also spaced approximately one frame period after frame A. That pattern supports steady delivery with a repeatable offset. It does not prove freshness relative to an external trigger, but it is not evidence of a duplicate image.

Contrast that with completion at 1028.0 ms and dequeue at 1094.6 ms. The post-completion interval becomes 66.6 ms, approximately two frame periods. Investigation should then focus on consumer scheduling and queue residence.

Frame identifiers establish sequence continuity, not complete end-to-end latency. For image-to-result association, follow matching asynchronous vision results to their source frames.

Test likely causes in order

When backlog is demonstrated, the relevant follow-on is multi-camera callbacks and buffer queues. Increasing buffer count can prevent loss during short stalls, but it can also allow more old frames to accumulate.

A latest-image policy may suit a live preview. It is usually wrong when every inspected part requires a traceable result. Frame dropping must be an explicit application decision, not an undocumented side effect of a freshness fix.

Choose hardware only after locating the delay

Do not replace a camera or cable because a timestamp is earlier than dequeue time. First establish whether the limiting interval is exposure, readout, transfer, completed-buffer waiting, or downstream processing.

For replacement planning, compare area scan cameras in the camera finder. Interface, payload, shutter behavior, and the documented timing features all matter; an interface label alone does not establish end-to-end latency.

The LS-CMR-0053 is a GigE option to evaluate. Verify its timing documentation and suitability for the required acquisition behavior before selecting it.

The LS-CMR-0166 provides a USB3 alternative for interface planning. Its presence here does not imply that either camera exposes every timestamp discussed above.

Check camera cables through the accessories finder when transport faults are independently indicated. Verify connectors, routing, motion requirements, and the complete host connection rather than assuming a different cable changes timestamp semantics.

For a USB3 cable candidate, review the LS-CBL-0219. Confirm compatibility with the selected camera and host before ordering.

Verify the diagnosis and choose the next action

Use a compact acceptance checklist after making one controlled change:

• Timestamp meaning documented: every recorded field has an event definition, unit, and clock source.
• Sequence checked: frame identifiers reveal gaps or repeats, with rollover handled correctly.
• Transfer separated from waiting: completion timing distinguishes receive duration from post-completion delay where supported.
• Sustained behavior measured: report typical and high-percentile intervals, plus the maximum and the test conditions.
• Buffer ownership correct: processing cannot read memory that acquisition has already reused.
• Application policy explicit: preserve every frame or intentionally discard superseded frames according to the inspection task.

If the complaint concerns what appears on a screen, dequeue timing is only an intermediate measurement. Use glass-to-glass camera latency measurement to include processing and display behavior.

Keep a known-good trace with the configuration so future changes can be compared against the same event definitions. If hardware selection remains necessary, start with the camera configurator. For help interpreting a trace, send the configuration and timing definitions through applications support.