Alexander Noé, Autor der AVI-Mux GUI, hat auf seiner Webseite in englisch eine tabellarische Übersicht über Behauptungen zum AVI-Kontainer, und seine Ansicht dazu - meist konnte er Vorurteile durch Tests entkräften. Diese möchte ich hier auf deutsch übersetzt präsentieren:
-
AVI hat Probleme mit großen Dateien
Völlig falsch. AVI unterstützt Dateien, die größer sein können als jede derzeit verfügbare Festplatte. Allerdings kann manche schlechte Software AVI-Dateien größer als 4 GB nicht verarbeiten, obwohl dies bereits seit den 28.02.1996 spezifiziert wurde.
Anmerkung von mir: Wer von AVI spricht, sollte gleichzeitig auch die Versionsnummer der Spezifikation nennen, mit der das jeweilige Programm umgehen kann (1.0, 1.1, 2.0 / OpenDML)... -
AVI unterstützt nur 1 oder 2 Tonspuren.
Völlig falsch. AVI-Mux GUI ist der Beweis.
Anmerkung von mir: VirtualDub / Nandub verwendeten ein recht eingeschränktes Bedienkonzept - sicher stammt diese Vermutung daher; VirtualDubMod mit der Streams-Liste ist da mittlerweile flexibler. -
AVI unterstützt keine Untertitel.
Falsch. AVI-Mux GUI und DirectVobSub/VSFilter widerlegen das.
Auch der SubtDS-Filter von Tobias Waldvogel könnte da helfen, und auch einige Media-Player zeigen selber Untertitel an, ohne Filter zu benötigen. -
Untertitel in AVI können nicht geschnitten werden.
Es gibt sicherlich einfachere Dinge auf der Welt als dies. Schneiden / Verbinden von Untertiteln in AVI-Dateien erfordert, dass die gesamten Untertitel-Blöcke interpretiert, verarbeitet und wiederaufgebaut werden, was eine recht erhebliche Arbeit ist. Das Verbinden von Untertiteln in AVIs ist recht ähnlich zum Verbinden von reinen Untertitel-Textdateien.
Allerdings kann AVI-Mux GUI das mit SRT- und SAA-Untertiteln. -
AVI erfordert einen großen Overhead.
Teilweise richtig. VBR-MP3 verursacht recht viel Overhead, die meisten CBR-Audioformate jedoch eher nicht. (Und selbst bei VBR-MP3 ist er geringer als in OGM.)
Für genauere Informationen über AVI und Overhead schaue man in die Overhead-Seite (englisch). -
VBR-MP3 in AVI ist ein dreckiger Hack
Positionieren in einer VBR-MP3-Tonspur funktioniert in DirectShow, als wäre es eine Video-Spur, keine Audio-Spur: Jeder Chunk beinhaltet Daten für eine gewisse Zeitdauer (üblicherweise 33 oder 40 ms, oder 24 ms bei VBR-MP3). Der Chunk, der geladen werden soll, ist einfach (Zeit) / (Dauer des Frames). Obwohl die Art, wie in VBR-MP3 positioniert wird, für AVI funktioniert, ist er jedoch grundsätzlich für Tonspuren ungeeignet! Insofern ist es tatsächlich ein Hack, allerdings weniger "dreckig" als manche glauben.
In der ursprünglichen AVI-Spezifikation ging man grundsätzlich von CBR für Tonspuren aus, und hatte sie so meist regelrecht als Synchronisations-Referenz verwendet. -
AAC in AVI funktioniert nicht.
Dies funktioniert seit AVI-Mux GUI Version 1.15.4. Diese Dateien spielen genau so mit dem MS AVI-Splitter wie mit dem von Gabest. Die Technik, VBR-Ton in AVI unterzubringen, ist die gleiche wie bei MP3. -
AC3 in AVI ist problematisch.
Teilweise richtig. Allerdings liegen solche Probleme NUR an schlechten Filtern und schlechter Hardware! Wenn man korrekte Multiplex-Muster verwendet, dann können alle Fehler in Filtern und Wiedergabehardware umgangen werden. -
AVI unterstützt keine bidirektionale Codierung
Der AVI-Kontainer wurde nicht erschaffen, um B-Frames zu speichern, weshalb nicht zu unterscheiden ist, ob ein Frame P oder B ist, ohne Daten zu decodieren.
DivX und XviD interpretieren diese Spezifikation auf eigene Art, um sicherzustellen, dass ein Chunk sich immer nur auf einen vorhergehenden Chunk bezieht, und nicht auf einen folgenden. Das ist eine interessante Beugung der AVI-Spezifikationen, und kann klar als Hack gelten.
Damit sind wohl die "Packed Bitstreams" gemeint, die B-Frames mit dem zukünftigen P-Frame kombinieren, und anstelle der überprungenen B-Frames dann keine Frame-Daten beinhalten. -
AVI ist nicht streambar.
Teilweise richtig. Es ist nicht möglich, die gesamte AVI-Ausgabe zu streamen. Die AVI-Mux GUI benötigt beim Schreiben von AVIs zwei Positionierungs-Operationen nach jedem Gigabyte Daten.
Es ist möglich, AVIs zu erzeugen, die im Streaming-Modus ohne weitere Positionierungen gelesen werden können. Es liegt nicht an mir, dass es keinen Filter gibt, der diese Möglichkeit nutzt, ohne dass man ihn mit speziellen Methoden davon überzeugen müsste. -
AVI braucht mehr Overhead als OGM oder MKV.
Falsch für OGM, und richtig für MKV, wenn EMBL- und "fixed" (festes/korrigiertes?) Lacing verwendet werden. Siehe Overhead-Vergleich. -
AVI unterstützt keine anamorph encodierten Filme und die Speicherung von Seitenverhältnissen.
Völlig falsch. Der Open-DML AVI-Standard beinhaltet einen VIDEOPROPERTYHEADER für Video-Streams, was einen Hinweis auf die Ausgabe-Auflösung im Sinne von Matroska's DisplayWidth- und DisplayHeight-Elementen erlaubt.
Das Problem ist, dass DirectShow diese Werte nicht ausliest (zumindest erwähnt die DirectShow-Spezifikation keine Unterstützung für dieses Feature). Aber das ist eine weitere Schwachstelle in Microsoft's Versuch, das AVI-Format zu unterstützen. Es ist nicht eine Schwachstelle des AVI-Kontainers.
