AVI codec file IO error: get frames from converted video

You converted a .wmv clip to .avi, pointed your vision software at it, and the first frame read returns a file IO error — while the same clip plays in a media player and clips your own system recorded read fine. That combination points at the reader, not your code. Vision libraries ship a short, fixed list of AVI codecs, and a converted file usually still carries the compressed codec it started with. The path is the same for inspection replays, training sets or supplier samples: read the codec tag out of the file, re-encode one clip to a format your reader decodes, verify the frame count, then batch-convert the rest.

What the file IO error is telling you

The failure pattern is specific. The path exists, the file size and duration show up correctly in the file browser, and the read call fails on frame 0 every time. That means the reader opened the file, parsed the AVI header and found a video stream, but could not produce a single frame from it. Vision readers report an undecodable stream as a file IO error, because from the call's point of view the read failed. The file is not corrupt.

Two quick facts confirm it. A clip the same software recorded itself reads without error, so the pipeline works. The converted clip plays in a media player, so the pixels are intact. Players and vision readers simply carry different decoder sets: a player loads the system's decoders and falls back until one renders the file, while a vision reader loads only the decoders compiled into it. If your file will not even open, that is a different failure — start with the capture backend checks for AVI open errors.

The cause behind almost every case

.avi and .wmv are container formats: they describe how frames, audio and index data are packed, and each video stream carries a codec tag naming the decoder it expects. The extension is only a label. Conversion tools aim at playback, so their default output is a compressed codec from the MPEG-4 or H.264 family — small files that every player handles. Vision SDKs bundle a much shorter list: uncompressed 8-bit and 24-bit frames, some YUV formats, Motion JPEG, occasionally H.264.

So the converted file is healthy and unreadable at once. The container says AVI; the stream names a codec the reader has never heard of. Work to this rule: if the stream's codec tag is neither plain uncompressed nor a codec your reader's own recordings use, the error stays until you re-encode.

Read the codec tag in two minutes

Any converter or player with a media-information view prints the video codec for a file. Note the four-character code, called a FourCC, that it reports. Common values: MJPG for Motion JPEG, H264 for H.264, WMV3 for Windows Media Video 9. An uncompressed RGB clip often carries no codec name at all, because each frame is stored as a plain bitmap rather than a compressed stream.

One trap hides in the word uncompressed: it is a family, not a single format. Converters offer packed variants such as v210 (10-bit 4:2:2) and v308 (packed 4:4:4), and most vision readers load plain 8-bit RGB and nothing else from that family. Unless your reader names the variant, convert to 24-bit RGB.

The decision: uncompressed 24-bit RGB as the target, Motion JPEG when disk space is tight and your reader lists MJPG.

Rank the causes, then test each in minutes

The codec mismatch explains most cases, but run the quick tests before converting anything:

The first row decides the fix. The other rows matter when a clean re-encode still fails.

Fix it: re-encode one clip, verify, then batch

1. Record or export a five-second clip with the vision software itself and read it in your code. Its codec tag is the definition of what your reader decodes.
2. Convert one clip from the .wmv set with a transcoder that sets every output parameter by hand: video codec uncompressed 24-bit RGB (or MJPG if that is what your reader uses), frame size unchanged from the source, frame rate entered as the source value, audio stream removed.
3. Check the result: the probe shows the expected tag, and the file size sits close to width × height × 3 bytes × fps × seconds.
4. Read frame 0, a middle frame and the last frame in your software. All three must return pixels.
5. Batch-convert the rest with identical settings, and check every converted file's frame count against fps × seconds before processing it.

Worked example: size, frame count and the 2 GB wall

Take a 640 × 480, 24-bit RGB clip at 30 fps that runs for 45 s:

• Bytes per frame: 640 × 480 × 3 = 921,600 B
• Data rate: 921,600 B × 30 = 27,648,000 B/s ≈ 27.6 MB/s
• Clip size: 27,648,000 B/s × 45 s = 1,244,160,000 B ≈ 1.24 GB
• Frames: 30 × 45 = 1,350

The 45-second clip fits a classic AVI comfortably. A 3-minute clip does not: 27,648,000 B/s × 180 s = 4,976,640,000 B ≈ 4.98 GB, past the 2 GB limit of the original AVI 1.0 layout that many vision readers still enforce. Divide the limit by your data rate for the per-file budget: 2,000,000,000 B ÷ 27,648,000 B/s ≈ 72 s per file. A reader hitting that wall fails partway through the file rather than at frame 0 — a different cause wearing the same error message. The fix for the 2 GB AVI file limit covers that case in depth. Motion JPEG compresses roughly 10:1, which keeps the same 3-minute clip near 0.5 GB, inside the old limit.

If a clean re-encode still fails

Work down the remaining rows of the table. Copy files to a local disk before reading: network shares and interrupted copies produce both zero-byte files and truncated ones, and the size check catches both. If frames now read but colors or layout look wrong, the pixel data arrived in an order your math did not expect; handle that after the read, as in Convert a raw camera buffer to a processing-ready image.

If even the five-second self-recorded clip fails, stop blaming files. The problem sits in the reader or its environment, and the stage-by-stage signal checks used when a capture card reports no video source apply here too.

Verify the frames before you process them

Three checks, all fast:

• Count. The reader should return 1,350 frames for the 45-second example. A large shortfall means the converter dropped frames or resampled the rate; reconvert with the frame rate entered by hand.
• Timing. If downstream logic depends on the time between frames, measure the delivered rate from frame timestamps instead of trusting the header — Camera frame rate measurement from timestamped frames shows the method.
• Depth. Confirm the bit depth and channel order of the data you actually got before doing math that assumes 8 bits per channel — Read image header bit depth before loading image files.

Prevention: make the conversion step boring

• Convert first, process second. Never point the pipeline at an original .wmv.
• Keep one batch script and one settings profile, and write a manifest per set: source file, output codec, frame rate, frame count, check result.
• Make the pipeline assert codec tag, resolution and frame count at load time and stop loudly on a mismatch. A silent frame drop corrupts results downstream for hours.
• Recording AVIs from your own code and getting empty files is the same story on the write side — see VideoWriter writes an empty AVI file: feed it BGR frames.
• If the goal is frames from a live line, skip files entirely: pull from the camera or a frame grabber and match processing to the arrival rate, as in Acquisition faster than processing: fix the frame rate gap. The batch conversion itself is disk-and-CPU work that a vision controller sized for your camera load runs alongside acquisition.

A 60-second checklist before processing converted clips

• Codec tag is plain uncompressed 24-bit RGB or MJPG — a decoder your reader ships.
• Frame count equals fps × seconds, within one frame.
• Width and height match the source; nothing was rescaled.
• File size sits near width × height × 3 bytes × fps × seconds.
• The container holds no audio stream.
• Frame 0, a middle frame and the last frame read without error.
• Originals kept; converted set in its own folder beside the manifest.

Convert one clip with the settings above and read frame 0 — that closes the loop in ten minutes. If this is part of building the station that records the clips in the first place, the system configurator walks camera, capture and processing choices in order, and the systems learn topic collects acquisition-side fixes like this one. If a clip still fails after every check here, send the codec tag and the exact error text through the contact page.