Recording a compressed AVI from a camera stream: codec availability

The compressor list comes back empty, or the filter-names call the help file documents is not in the installed library at all, and the camera itself is fine. That combination misleads people into reinstalling camera drivers. The problem lives two layers away, in the video codecs registered on the recording PC and in the version of the vision library you are calling. This page is for engineers recording inspection footage from area scan cameras to AVI files on Windows. It covers where the codec list actually lives, why an older library release can lack the function entirely, how process bitness hides codecs, the storage arithmetic that tells you whether you need compression at all, and a ten-minute test that proves a codec before it reaches the line.

Why is the compressor-list call missing from the vision library?

The AVI-compression functions, including the call that lists filter names, ship in the release of the vision library that added AVI writing. A help file documenting a call your installed library lacks means a version mismatch that no codec install can fix.

Confirm it before changing anything. Read the library version the way you read any DLL, from the file's version details, and compare it against the release the help file describes. Functions arrive in sets: the calls to list compressors, create the file, write frames and close appear together in the release that added AVI compression. Finding the writer but not the list call points at a mixed installation, so uninstall the old run-time completely before installing the new one.

The fix is the supported one: install the newer library release from its maker or your distributor. If the station is validated and cannot take an upgrade, two honest options remain. Record through a standalone capture utility on that machine, one that enumerates the operating system's codecs itself, or log raw frames from the station and compress them offline on an engineering workstation.

A missing function is a version problem, not a broken installation. The startup failure caused by a missing DLL is a different fault, and the missing-DLL startup diagnosis page covers that one separately.

Where does the AVI codec list actually come from?

The list comes from Windows itself: the legacy Video for Windows layer keeps a registry of installed compressors, and your recording library builds its filter-name list from that registration table rather than from anything the camera or capture driver supplies.

Video for Windows is the old API behind the AVI container, and it keeps installable compressors as registered drivers. In the registry they sit under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\icm, one vidc.<four-character code> key per compressor. On 64-bit Windows, 32-bit registrations live under that path's Wow6432Node. Your library's list call reads that table; it carries no codecs of its own.

Two enumerations are easy to confuse here: capture devices and compressors. A camera that lists correctly in your capture tool proves nothing about compressors, because Windows enumerates the two independently. Microsoft documents the device side of that split on its page about enumerating video capture devices.

So an empty list has exactly one meaning at this layer: nothing of the matching architecture is registered. Newer encoder stacks, such as Media Foundation filters or encoders built into the library itself, never appear in a Video for Windows filter-name list, so do not expect a modern codec name there.

Why does the application see no codecs when another application does?

Video for Windows compressors are registered per architecture: a 32-bit process enumerates only 32-bit codecs and a 64-bit process only 64-bit ones. A codec another application lists can be invisible to yours even on the same machine.

Compressors load in-process, which is why the architecture must match your executable, not Windows. Use the Wow6432Node split from the previous section to see which side each registration sits on, then run your own enumeration twice, once as a 32-bit process and once as 64-bit, and compare the two lists. That five-minute comparison settles most codec arguments on the bench.

If the codec you need exists only in the other bitness, either install a build matching your process from the codec vendor's installer, or run the recorder as a process of the bitness the codec supports. Converting the recorder to 32-bit is often the faster fix on a legacy line; adding a 64-bit codec is the durable one.

One more mismatch to rule out: query the same API layer you write with. A list pulled from one layer tells you nothing about what a writer built on another layer will accept, so keep the enumeration call and the write call in the same library.

How do you prove a codec works before it reaches the line?

Test on the target machine with real production frames, one codec at a time — record ten seconds, log file size and CPU use, decode the file back and inspect the pixels. A codec that plays well on an office laptop can still stall a line PC.

1. On the recording PC, call the filter-names function from a process built with the bitness you will deploy, and print the list. Note the count and the bitness next to it.
2. Record a 10 s clip per candidate codec at full frame size and rate, with production parts in view. Same scene every time, or the size comparison means nothing.
3. Log file size and CPU use during each recording. Encoding rate is file size divided by 10 s; against the 62.2 MB/s raw example in the next section, a codec measuring 10:1 writes about 6.2 MB/s.
4. Decode each file back to frames and difference them against the raw input. Any feature you measure on must survive the round trip. If a reader refuses a file, the AVI open-error and backend fallback page is the starting point on the read side.
5. Watch the timing. A file that runs shorter than the wall-clock recording period, or tears mid-frame, means the machine cannot hold that codec at that frame size; the recording faster than real time page separates acquisition stalls from encoding stalls. Frames lost mid-write also show up as partial frames — the same signature documented for offline robot-simulation recorders in this partial-frame AVI recording troubleshooting note.
6. Write the winning codec's name and settings into the deployment notes, and store them beside the recorded files.

Prevention is short: pin the library version, install codecs machine-wide before rollout, and re-run the enumeration once after every software change on the recording PC.

What does an uncompressed camera stream cost in storage?

At 1920 × 1080, 8-bit mono and 30 fps, a raw stream is 62.2 MB/s — about 3.7 GB per minute or 224 GB per hour — so this arithmetic, not a codec table, decides whether compression is optional. Compute it as width × height × bytes per pixel × fps.

Worked example, with illustrative inputs of 1920 × 1080, mono 8-bit and 30 fps:

• 1920 px × 1080 px = 2,073,600 pixels per frame
• 1 byte per pixel → 2,073,600 bytes per frame
• × 30 fps = 62,208,000 bytes/s ≈ 62.2 MB/s
• × 60 s = 3,732,480,000 bytes ≈ 3.7 GB per minute
• × 3600 s = 223,948,800,000 bytes ≈ 224 GB per hour
• one 8-hour shift ≈ 1.79 TB raw; at a measured 10:1 ratio ≈ 179 GB per shift

Treat 5:1 to 20:1 as the usual range for lossy settings on parts content and take your own number from the 10-second test in the previous section. A GigE link carries roughly 110-120 MB/s of usable payload, so this example stream fits one link with little left for anything else on it. Full-array recording at 4000 × 3000 and 30 fps moves 360 MB/s, which one GigE link cannot carry at all; a USB3 link can, which is why the 12 MP USB3 camera below suits local recording onto the controller.

When should you save stills instead of a compressed AVI?

Whenever anyone will measure from the recording, save individual frames losslessly instead of trusting a compressed AVI. A lossy compressor rewrites pixel values by design, and a dimension check on the file then measures the codec's choices rather than the part.

Split the footage by purpose. Review clips, shift handovers and training material belong in a tested lossy codec. Measurement, classification datasets and anything a gauge reads belong in lossless stills — saving consecutive camera images needs no code — or in an AVI created with no compressor selected, which most vision-library writers treat as raw frames and which costs the storage the previous section computed.

An AVI that writes zero frames is a separate failure from an empty codec list, usually the frame format handed to the writer; the empty AVI from a wrong frame format page covers that one.

Which machine should record the stream?

Run the writer on a dedicated vision controller sized from the storage section. An uncompressed 1080p30 mono shift needs about 1.8 TB of free space, and the controller needs a port per camera plus headroom of at least one processor core for the encoder.

Size the disk from that number, not from habit. At the 10:1 example ratio a shift writes about 179 GB, so a 1 TB drive buffers roughly five shifts of review footage before offload; uncompressed, plan 1.8 TB per shift or shorten retention accordingly.

Three vision controllers cover the usual cases. The MV-VC2140-128G40-1T carries 8 GB of memory, a 128 GB SSD and a 1 TB HDD, which makes it the single-camera recorder with local retention. The MV-VC3301H-128G66 steps up to an Intel Core i3 with 8 GB of memory, 5+ LAN ports and 3-4 USB 3 ports for a multi-camera cell. The MV-VC5525-256G70-NN adds a 12th-generation Intel Core i5, 32 GB of memory, PoE camera ports, 8 built-in light channels and PCIe expansion.

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Decision, by case:

• Filter-names call absent → upgrade the vision library from its maker or distributor; until then record uncompressed or compress offline.
• List empty → install a matching-bitness codec machine-wide from the codec vendor, then re-run the enumeration.
• Codec listed but the recording drops frames → cut the ROI or frame rate, or move the writer to a controller with more free cores.
• Footage for measurement → lossless stills or an uncompressed file; footage for review → the tested lossy codec, with its name and settings stored beside the files.

The rest of the recording and streaming faults — empty files, stalled pipelines, missing components — sit on the systems guides topic. If you want the storage or port math checked against your cell, send the camera count and retention target through the contact page and we will work it with you.