VideoLAN says it in its own documentation: "The avi muxer in VLC is known to produce corrupt files." That sentence sits directly under the AVI entry in VLC's official Streaming HowTo, in the section that lists every container VLC's stream output can write.
So the broken file you just produced with Media → Convert/Save is not necessarily a settings mistake on your side — it is a documented property of one specific component. The fix is not "find the right AVI settings." It is "stop asking VLC to write AVI."
What "corrupt" actually means here
VLC's conversion feature is not a separate converter. VideoLAN's Transcode page puts it plainly: "In VLC, transcoding is exactly the same as streaming across a network, except that the output is sent to a file instead of a network." That is why every option is named --sout-*, and why a "Streaming" entry appears in your playlist while a conversion runs.
Official documentation separates the two concepts clearly. A codec is "a compression algorithm, used to reduce the size of a stream." A container format "contains one or several streams already encoded by codecs." And in VLC's stream output, the mux option is the one that "allows you to set the encapsulation method used for the resulting stream" — avi is one of the values that option takes, and it is that value the warning names.
One honest caveat about that quote: it carries no version number and no "fixed in" note, and VideoLAN's documentation index warns that "Parts of this documentation are currently outdated or incomplete." Treat it as a documented, unretracted warning rather than a guarantee about the build on your machine — and test either way, using the 30-second check below.
What the AVI muxer will even accept
The same official page lists AVI's supported streams, verbatim:
avi: the Microsoft AVI muxer. This is very common encapsulation format for
MPEG-4 files. The only supported output method is file. Supported codecs are
MPEG 1/2/4, H263, H264 and I263 for video, MPEG audio and a52 for audio streams.Broken down, that whitelist is narrow:
- Video: MPEG 1/2/4, H263, H264, I263
- Audio: MPEG audio, a52
- Output method: file only
Anything outside that list is where the second failure mode lives. VLC's Transcode page — which carries its own warning, "This page is outdated and information might be incorrect." — describes it directly: "If you choose an incompatible stream for a given muxer, it may silently fail. You can look for error messages in the messages window to help you debug the failures."
Silently. No dialog, no red text, just a file that is wrong. The companion page in the official Documentation set explains why this class of problem exists: "In a perfect world, you could put any codec in any container format. Unfortunately, there are some incompatibilities."
One wrinkle before you go hunting: the Transcode page tells you to "look at streaming features compatibility matrix" — and that page now returns nothing but "There is currently no text in this page." The table VideoLAN points you at no longer exists. The per-muxer descriptions above, plus what your own build reports, are what is left.
The fastest fix: write a different container
Pick a muxer the documentation actually covers, or take the container step out of VLC entirely.
If you stay inside VLC, ts has the widest codec whitelist of the documented set: "Supported codecs are MPEG 1/2/4, MJPEG, H263, H264, I263, WMV 1/2 and Theora for video, MPEG audio, AAC and a52 for the audio stream." It is also the only one of them that lists AAC.
If what you want is a modern general-purpose container, do the container change elsewhere:
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
This runs in your browser tab — the file is read from disk, rewritten locally, and handed back, with nothing uploaded. The standalone page is MP4 to MKV, and the rest are on all Clapr tools.
One note on that documented muxer list: it covers ts, ps, mpeg1, ogg, asf, asfh, avi and mpjpeg. It does not list mp4, mkv or webm — yet VideoLAN's own Transcode page uses mux="mp4" in a worked example on the same wiki. The list is incomplete, not a statement of capability. To see what your build supports, run vlc -H; the transcode module's docs explain why no static table can be right: "Since supported codecs are dynamically assigned by the running program, sout-transcode-venc, sout-transcode-aenc and sout-transcode-senc have been left blank."
Other causes, in order of likelihood
1. Your codec is outside the muxer's whitelist. Symptom: conversion appears to complete, output is broken or missing a track. Cause: the silent failure quoted above. Fix: open Tools → Messages during a conversion and read what the stream output reports, then either transcode to a codec on the list or change the muxer. The same mechanism is behind VLC conversions that come out with no audio — AVI's audio whitelist is two entries long.
2. Loop or repeat is enabled in the GUI. VideoLAN notes this verbatim: "(Note: without the options --no-repeat --no-loop, you may find that loop options selected in the GUI cause transcodes to fail.)" Turn loop off in the playlist before converting — it costs nothing to check.
3. You set width/height alongside a video filter. Official guidance, verbatim: "Avoid using width and height parameters, also maxwidth and maxheight! These are applied before the vfilter and might result in unwanted results."
4. The source AVI was already damaged. If VLC showed a repair dialog when opening the input, the input is the problem. VideoLAN's own support guide — which the site labels informal — is blunt about that dialog: "you can play as is or temporary repair the file, but you can't fix this problem definitively." The repair is per-session and not written back to the file, which is why the prompt returns every time.
5. The file came from a merge. If you built the input by combining clips in VLC, VideoLAN's own support guide — the one the site labels informal — warns about the result: "none of the ways VLC offers to combine streams appears to merge them with correct time signatures even when replayed in VLC (causing seeking errors), so a non VLC option might work better."
How to tell it worked
Do not convert a 40-minute file to find out. VideoLAN's own advice: "Transcoding takes quite a while, so it's advisable to use an option like --stop-time=30 to only encode the first 30 seconds—this means you can check the file has transcoded correctly, and that the output is of a suitable quality." On macOS the page adds that this trick "doesn't seem to work" and suggests pressing Ctrl-C partway through instead, after which "VLC will properly write out the already transcoded segment."
Check that sample in the player or editor the file is destined for, not only in VLC. And keep Tools → Messages open while it runs; that window is the official debugging entry point for stream output problems.
If you never needed to re-encode at all, keeping the original track skips the encoder entirely. For the same symptom in another tool, see OBS recordings that come out as corrupted MP4s. More conversion troubleshooting is in the fix category.
FAQ
Why does VLC create corrupted AVI files?
Because of the muxer, not your settings. VLC's official Streaming HowTo states that "The avi muxer in VLC is known to produce corrupt files." That line sits in the list of values the mux option accepts, and the documentation gives no further cause beyond it.
Is the VLC AVI muxer bug fixed in the current version?
The documentation does not say. The warning carries no version qualifier and no fix note, and VideoLAN's own index warns that parts of the docs are outdated or incomplete. Convert 30 seconds with --stop-time=30 and judge your own build.
What container should I use instead of AVI in VLC?
Of the muxers VideoLAN documents, ts accepts the widest codec list, including AAC audio. If you want MKV or MP4 specifically, the official muxer list does not cover them, so the predictable route is to do the container change outside VLC.
VLC said the conversion finished but the file is broken — why was there no error? Because it may not produce one. The documentation states that an incompatible stream for a given muxer "may silently fail," and points you to the messages window (Tools → Messages) to find the errors that were not surfaced in the UI.
Can VLC repair an AVI that is already corrupt? Only temporarily. VideoLAN's informal support guide says you "can play as is or temporary repair the file, but you can't fix this problem definitively." The repair is not written back to the file.
Can VLC output MP4 or MKV directly?
The official muxer documentation does not list them, but VideoLAN's own wiki uses mux="mp4" in an example, so the list is plainly incomplete rather than a limit. Run vlc -H to see what your build actually exposes, and check the official documentation for anything the enumerations leave ambiguous.
Everything above is quoted from VideoLAN's own wiki — the Streaming HowTo muxer reference, the Transcode page (which carries its own "outdated" warning), and the VLC Support Guide (which VideoLAN labels informal) — as captured on 16 September 2026. Where the documentation is silent, this article says so rather than guessing.
