Stable camera acquisition: buffers, timeouts and reconnection

Problem and prerequisites

A grab loop can return valid frames yet leak buffers or reuse old images after reconnection. Confirm buffer lifetime and removal events in the actual SDK. The appendix below is vendor-neutral pseudocode, not executable SDK calls or a Deyi capability claim.

Prepare the test

Assume 2000 × 1500 Mono8 images: 3 MB each, so 8 raw buffers occupy 24 MB before metadata and processing copies. Fix a device identity and define a new acquisition generation after every reconnect.

Read the chosen SDK’s acquisition and lifetime documentation before designing the worker loop. Identify who allocates buffers, who owns a grab result, when a buffer returns to the driver and whether a retained reference remains valid after that return. Confirm the documented removal notification and the thread on which it occurs. Keep state changes and shutdown coordination outside a notification callback when the SDK forbids blocking there. Define device identity using a documented stable identifier rather than the first device found after enumeration. Record image dimensions, pixel format, payload size, trigger mode and transport configuration as the accepted acquisition set. None of the conceptual operation names below promises a Deyi SDK interface.

Procedure

1. Configure dimensions and pixel format before allocating buffers from the SDK-reported payload size.
2. Acquire with a bounded timeout; distinguish no trigger, transfer failure and device removal.
3. Copy or retain the image under documented ownership rules before releasing the grab result.
4. On removal, stop workers, return outstanding buffers and discard pending results from the old generation.
5. Reconnect only the expected device, reapply and verify configuration, then resume with a new generation identifier.

VENDOR-NEUTRAL PSEUDOCODE — conceptual operations, not SDK API names
connect(expected_device_identity)
verify_configuration_and_payload()
generation = new_generation()
while connected:
    result = none
    owned_image = none
    try:
        result = acquire_with_deadline()
        if result.is_valid:
            owned_image = copy_or_retain_under_documented_rules(result)
            process(owned_image, generation)
        else:
            record_acquisition_fault(result, generation)
    finally:
        release_owned_image_if_present(owned_image)
        release_grab_result_if_present(result)
on_coordinator_receives_device_removed:
    invalidate_current_generation()
    stop_and_join_workers()
    return_all_buffers()
    discard_old_generation_results()
    reconnect_expected_device_and_verify_configuration()
    generation = new_generation()

Acquire with a finite deadline and inspect the result before accessing its payload. A timeout may mean that no external trigger arrived; a transfer fault or device removal requires a different recovery path. Associate each valid frame with acquisition generation and frame or event identity before handing it to processing. Either copy to application-owned storage or retain ownership using the SDK’s documented rule. In both cases, release resources on processing exceptions as well as normal completion. Bound the processing queue and define what happens when it fills. Silently growing memory is not a valid backpressure strategy, and reusing the most recent frame for a new request is not a valid substitute for a missing image.

Illustrative test record

Illustrative assumptions, not measured Deyi performance. Replace these values with your own signed test records.

Force a slow consumer while maintaining the configured capture rate. Log acquisition generation, frame identifier, queue depth, live buffer count and timeout reason. If images are copied, the 24 MB calculation excludes those copies; if references are retained, the SDK must permit their lifetime. The finally block illustrates release on processing exceptions too. After reconnection, inject a delayed old-generation result and confirm that it cannot become a current inspection result.

On removal, stop accepting new work for the affected generation and coordinate worker termination before freeing resources they may still access. Cancel or complete outstanding operations according to the SDK contract, return buffers and discard unconsumed old-generation results. Reconnect the expected device and verify the accepted configuration rather than assuming defaults match the previous session. Read back payload information before allocating new buffers. Create a new generation only after the new session is ready. A late callback or queued result from the old session must be rejected by generation checks even if its frame number resembles a current frame. The example’s raw-buffer arithmetic is only one component of memory consumption; include copies, queues and algorithm workspace in a measured budget.

Two views of the workflow

Troubleshooting

• Increasing memory is a sign of unreleased results or unlimited consumer queue.
• Corrupted images suggest use after a buffer was returned to the driver.
• Repeated stale images after reconnect require checking queues and generation identifiers, not just reopening the device.

Acceptance and handover

Run the illustrative 1000-frame trial plus removal, restoration and shutdown cases. Confirm bounded memory, no cross-generation results and explicit faults instead of reused images. Repeat with a slow consumer; raw-buffer arithmetic is not a total memory budget.

Set acceptance limits before testing and retain the original evidence. The examples here do not establish a supplied model’s capabilities.

Acceptance combines sustained acquisition with deliberate interruption and a slow-consumer scenario. Log live buffers, queue depth, process memory, generation transitions and terminal reasons for every planned request. Remove and restore the device under a controlled procedure, then stop the application while acquisition is pending. Confirm that shutdown completes, no worker touches released memory and no old image becomes a new inspection result. Test processing exceptions to exercise the finally path. Compare the final device identity and configuration with the accepted record before release. The illustrative 1000-frame run provides functional coverage, not a long-term leak or reliability guarantee. Handover includes the actual SDK version, ownership decisions, queue policy, reconnect sequence and fault evidence, with executable vendor-specific code reviewed against its own documentation.

Related reading

Read the related selection and application guides before choosing equipment. For an engineering review, provide sample images, the required result, operating conditions and the completed test record.