| AVI has problems with large files | Totally wrong. AVI supports files larger than any current hard discs. However, some software, like the firmware of many hardware MPEG4 players, cannot handle AVI files larger than 2 GB, although these have been specified more than 10 years ago |
| AVI can only handle 1 or 2 audio streams | Totally wrong. A few people who think to write container comparisons still believe this, or even write such disinformation in order to make up advantages of OGM that do not exist, although even the original AVI file specification supports 256 streams * (no matter how many of them are audio or video), and although AVI-Mux GUI has been able to create AVI files with multiple audio streams for years |
| AVI cannot handle subtitles | AVI can work with text subtitles, as AVI-Mux GUI and DVobSub/VSFilter prove. |
| Subtitles in AVIs cannot be cut | There are indeed things easier to implement than this. Cutting / Joining subtitle streams of an AVI file requires that the entire subtitle data blocks are interpreted, processed and rebuilt, which is quite some work to code. Joining subtitles in AVI files is very similar to joining plain subtitle text files. However, AVI-Mux GUI can do this with SRT and SSA subtitles. |
| AVI files have a lot of overhead | MP3-VBR caused indeed a lot of overhead (still less than OGM) before AVI-Mux GUI supported MP3 frame packaging into some kind of "macro frames". For almost all other formats, it was and is wrong. Only AAC-audio causes a lot of overhead, because packing several AAC frames into one chunk breaks current decoders. VirtualDub and derivates create files which are called hybride-files in AVI-Mux GUI terminology, and no not support packing several MP3 frames into one chunk, so the overhead those tools produce is actually the upper limit for AVI file overhead. |
| MP3-VBR-in-AVI is a dirty hack | This is probably the piece of disinformation most widely spread about AVI. Seeking in an MP3-VBR audio stream in DirectShow works as if it was a video stream, not an audio stream: Each chunk contains data for a constant amount of time (usually 33 or 40 ms for video, or 24 ms for MP3 audio at 48 kHz). The chunk/frame to be loaded is just [time] / [time per frame], as if it was a video stream. The way MP3-VBR is sought in is valid for AVI files. Maybe it was not intended to be used for audio streams, maybe it was, fact is, the specification doesn't limit any particular seeking strategy to any particular stream type! There is a value in the stream headers, called dwSampleSize, which is 0 in order to trigger VBR stream seeking. This is officially documented in the MSDN and not a hack, bug or whatever. The way MP3-VBR and AAC are stored in AVI are specified and completely compliant with the AVI file specification. |
| AAC in AVI does not work | This works beginning with AVI-Mux GUI 1.15.5 (1.15.4 had a bug with 5.1 AAC files). Those files play fine with Microsofts's AVI splitter as well as with Gabest's AVI splitter, neither of which has any special support for this. The used technique to store VBR in AVI is the same as with MP3. There are a lot of MP4 trolls, saying things like "you should not put AAC into AVI, it is a bad idea, MP4 is better for this, MP4 is more modern blah blah". Forget this nonsense, AAC in AVI is compliant to the AVI file specification. |
| AC3 in AVI is troublesome | Partially true. However, those problems are ONLY caused by broken filters and broken hardware! If those bugs are respected by the muxing application, there are no problems. |
| AVI does not support bidirectional coding | The AVI container has not been designed to store B-frames, so that there is no way to tell whether a frame is P or B without decoding any data.
XVID and DIVX interprete the specifications in a very individual way, to make sure that one chunk indeed only refers to the preceding chunk, and never to a chunk it preceeds. It is an interesting bending of the AVI specifications, but clearly qualifies for being a hack |
| AVI is not streamable | Partially true. It is not possible to entirely stream AVI output. When writing AVIs with AVI-Mux GUI, two seek operations are necessary after each Gigabyte of data. It is possible to create AVI files that can be read in streaming mode, without any seeking. It's not my fault is there is no filter available which makes use of that possibility without using special methods to convince it to. |
| AVI has more overhead than OGM or MKV | True for MKV, nonsense for OGM. See AVI causes lots of overhead |
| AVI does not support anamophically coded movies and storage of aspect ratios | The Open-DML AVI standard includes a VIDEOPROPERTYHEADER for video streams, which allows to indicate the output resolution in the sense of Matroska's DisplayWidth and DisplayHeight elements. The problem is that DirectShow does not read those values (at least the DirectShow documentation does not mention support for this feature). MPEG4 has an aspect ratio stored in the bitstream as well, and ffdshow as well as a few other decoders use this aspect ratio, raising the wrong impression that anamorphically encodec video would properly work in AVI. But truth is, AVI is as unsuitable for anamorphically encoded video as OGM. |