Empty camera recording file: check writer setup and cleanup

A working preview proves that frames reach the application; it does not prove that the recording writer accepts them. An empty file can come from failed writer initialization, incompatible encoding settings, mismatched frames, or cleanup that never runs. This troubleshooting sequence helps you separate those faults without changing a camera that already captures correctly. It also explains why snapshots can work while recording fails, and why audio needs its own acquisition and synchronization path.

Separate capture, writing, and playback faults

Treat recording as three separate stages: acquire a valid frame, submit that frame to an open writer, then finalize the recording. Test playback only after those stages have completed.

A still-image save exercises a different output path. Its success does not establish video encoder availability, correct recording dimensions, or container finalization. Likewise, a preview may resize or convert frames before displaying them, hiding differences in the original image data.

Use this table to choose your first test. The symptoms are clues, not definitive diagnoses.

A warning about an unavailable stream position or duration can be unrelated to recording. Live sources may not expose those properties. Investigate failed frame reads and writer diagnostics rather than treating every capture warning as the cause.

If a finalized recording opens through one decoder but not another, use the video capture backend fallback diagnosis. That is a different failure from never writing a valid recording.

Check writer initialization before enabling recording

Do not set the recording state merely because the writer constructor returned an object. First check the writer's documented open-status method and reject the recording request if initialization failed.

Check these conditions in order:

1. The destination directory exists and the application can write to it.
2. The complete filename points to the intended directory, not an unexpected working directory.
3. The filename is unique, and another application is not holding the destination open.
4. The selected recording backend includes the requested encoder and container support.
5. Frame rate is positive and finite, and dimensions come from an actual valid frame.
6. The writer reports that it opened successfully.

Log the requested filename, encoder identifier, container extension, frame rate, dimensions, and writer-open status. Where the API exposes it, log the selected writing backend too. Capture and writing can use different backends within the same application.

Encoder identifiers and filename extensions serve different purposes. The identifier requests an encoding method; the extension usually helps select a container. Changing an extension does not convert the encoding or install an encoder.

For example, MJPG with an AVI container can be a useful diagnostic combination when the installed backend supports both. It is not a universal compatibility guarantee. MP4 also requires an encoder and container combination supported by the actual runtime.

Derive the recording format from real frames

Read and validate a frame before choosing the writer dimensions. Requested camera settings may be rounded, rejected, or changed by negotiation. The returned frame is the relevant evidence.

For an array shaped as height, width, and channels, the writer's size argument commonly expects width followed by height. Reversing those values is a frequent integration error.

Consider a hypothetical capture returning a color array shaped 720 × 1280 × 3. Its image width is 1280 pixels, and its height is 720 pixels. A writer configured for 640 × 480 pixels does not match that frame, even if the preview displays it inside a smaller window.

Choose one explicit policy:

• Record the original frame and configure the writer to match it.
• Resize every recording frame to a fixed output size before writing.
• Convert every frame into a documented, supported recording representation.

Do not let preview resizing define recording behavior accidentally. A display image and a recording image can be separate arrays with separate purposes.

Check channel count and data type as well as dimensions. A writer expecting an ordinary color image may reject a single-channel image, an image with transparency, or higher-bit-depth sensor data. Convert deliberately, and retain original inspection data separately when the recording representation discards information.

After cropping, rotation, or format changes, validate the contract again. If recording dimensions must change, finalize the current file and open another writer. Do not assume an existing writer can accept a new shape.

Prove that frames reach the write call

Add counters at the boundaries of the pipeline. At minimum, track successful acquisitions, rejected frames, submitted recording frames, and write exceptions. Reset session counters only when a new recording starts successfully.

A useful diagnostic message reports the frame shape and type immediately before the first write. Repeat that check whenever capture configuration changes.

Do not label the submission counter as successfully encoded frames unless the API actually confirms that status. Some writing interfaces return no per-frame success value. A write call that returns without an exception is evidence of submission, not proof of a valid file.

Use a controlled test with a fixed frame count. For a constant-rate recording, expected playback duration is:

If you submit 300 frames and declare 30 frames/s, expected duration is approximately 300 / 30 = 10 seconds. Verify that after finalization by reopening and decoding the recording.

This arithmetic also exposes timing mistakes. If acquisition delivers 20 frames/s for 10 seconds, you collect about 200 frames. Writing those frames with a declared rate of 30 frames/s produces approximately 200 / 30 = 6.7 seconds of playback in a simple constant-rate pipeline. The frame-rate argument does not force acquisition to meet that rate.

Read the camera once per iteration and share that validated frame between preview, snapshot, and recording. An extra acquisition for a snapshot can consume a different frame and disrupt recording cadence.

For workloads that fail only under sustained capture, continue with high speed camera recording without dropped frames. Throughput tuning comes after basic writer correctness.

Make Stop and window close share reliable cleanup

Use explicit application states rather than independent flags that can contradict one another.

Handle a window-close event before attempting another display update. Otherwise, drawing into a destroyed window can raise an exception before normal cleanup runs.

Use this sequence:

1. Read the interface event and check for shutdown first.
2. On Start, open the writer, verify its status, and only then enter Recording.
3. On Stop, prevent further submissions, finish any accepted recording work, and finalize the writer.
4. Acquire one valid frame and distribute it to the active consumers.
5. On normal exit or an exception, run cleanup through a guaranteed finalization path.

Initialize the writer reference to an empty state before entering the main loop. Cleanup must check whether a writer exists before releasing it. Closing the interface before the first recording should be an ordinary supported operation.

After releasing a writer, clear its reference and return to Preview. Repeated Stop events should have no effect. A subsequent Start should create a fresh writer and filename.

In Python, put resource cleanup in finally blocks or suitable context managers. Structure cleanup so that an error releasing one resource does not skip the remaining resources. Keep normal exception reporting active rather than hiding all failures behind an empty exception handler.

If acquisition and encoding run in separate workers, establish one writer owner. Stop accepting new recording frames, signal the worker, let it drain or deliberately discard its queue, then let that owner finalize the file. Never release a writer while another worker can still call it.

The distinction between stopping recording and stopping acquisition is covered in stopping a camera stream without closing the application.

Verify the file instead of trusting its existence

After releasing the writer, reopen the output through a supported decoder. Check that frames decode, dimensions match expectations, and duration is plausible. A nonzero file size alone is not enough: a container can contain metadata without usable image frames.

For the controlled recording test, verify the decoded frame count where the decoder supports it reliably. Also inspect the first, middle, and last portions for repeated images, corruption, or an unexpected size change. Sequential decoding is stronger evidence than trusting a reported metadata count alone.

Exercise the shutdown paths separately:

• Open and close the application without recording.
• Start recording, then use Stop.
• Start recording, then close the window directly.
• Start, stop, and start another recording.
• Make the output directory unwritable and confirm a clear failure.
• Simulate a failed frame read and confirm cleanup still runs.

A failed acquisition must not be passed into preview conversion, snapshot encoding, or video writing. Report the failure and apply a defined retry or shutdown policy.

If queued frames become corrupted despite correct dimensions, inspect memory ownership. Some capture systems recycle image buffers after the acquisition callback returns. Follow the camera frame memory lifetime guidance before retaining references for asynchronous encoding.

Keep audio outside the image-only writer

An image-frame writer does not acquire microphone samples merely because its output filename uses a multimedia container. Audio requires an audio capture source, an encoder, and a muxing stage that combines audio and video tracks.

Use a media pipeline that explicitly supports both streams, or record them separately with timestamps and combine them afterward. Define a common timing reference and preserve timing information from acquisition, rather than assigning timestamps when data finally reaches storage.

Independent capture clocks can drift during long sessions. If synchronization matters, choose a pipeline that can reconcile timestamps and document its resampling, frame-dropping, or duplication behavior.

Prove silent video recording first. Then add audio and test synchronization at both the beginning and end of a longer recording. Adding microphone capture while writer initialization is still failing makes fault isolation harder.

Choose hardware only after isolating the software fault

A camera replacement will not repair an invalid output path or missing finalization call. Keep the existing capture source while proving the minimal recording path, unless acquisition itself is failing.

When selecting a production interface, compare area scan cameras through the camera finder. Check acquisition software support, returned pixel formats, and the intended recording path before ordering.

The LS-CMR-0053 uses GigE. Confirm the chosen acquisition interface exposes frames in a form your recording application can handle.

The LS-CMR-0166 uses USB3. Its interface alone does not establish support in a generic video-capture API.

For a station requiring integrated camera connections, evaluate vision controllers against the complete acquisition and encoding workload. Verify runtime, encoder, storage, and interface requirements separately; a controller category does not establish application compatibility.

Preflight checklist and next step

Before treating the recording path as ready, confirm:

• Initialization: recording starts only after the writer reports open.
• Format: every submitted image matches the chosen dimensions, channels, and data type.
• Accounting: counters distinguish acquisition, rejection, and write submission.
• Timing: the declared playback rate matches the intended timing model.
• Ownership: one path owns the writer and any queued frame memory.
• Cleanup: Stop, Close, and recoverable exceptions all finalize the active recording.
• Verification: the finalized file reopens and decodes, not merely appears in the directory.
• Audio: any required sound has an explicit capture and synchronization design.

Start with the fixed-frame test and keep its logs as a regression check. For hardware selection, use the camera configuration starting point. If compatibility remains uncertain, send the required interface, frame format, recording rate, and failure logs through applications support.