Interfacetypen: VfW und Kommandozeile (CLI)
Im Wesentlichen existieren heute zwei Möglichkeiten, um einen Encoder zu konfigurieren: das grafische VfW und die textbasierte Kommandozeile (CLI). Welches Interface wir verwenden, hängt hauptsächlich vom Encoding-Frontend ab. Das stellt normalerweise auch eine grafische Oberfläche für CLI-Encoder bereit. Niemand ist also gezwungen, kryptische Befehlszeilen zu tippen. Die ausführlichen Erklärungen, die in den nächsten Kapiteln zu den Parametern der CLI-Encoder folgen, sind trotzdem fürs Verständnis nützlich, welche Option sich wie aufs Encoding auswirkt.
Das VfW-Interface
VfW steht für Video for Windows, ein Videoframework von Microsoft, das seit Windows 3.1 existiert und die AVI-Datei eingeführt hat. Wegen einiger Beschränkungen der Technologie – z.B. ist VfW nicht darauf ausgelegt, B-Frames zu speichern – mussten für moderne Codecs Hacks entwickelt werden. Besonders nachteilig ist das für MPEG-4-Codecs, da dadurch die MPEG-4-Spezifikation verletzt wird. Es ist also nicht möglich, z.B. Xvid mit B-Frames in AVI zu speichern, ohne mit den Regeln des Standards zu brechen. Andere neuere Technologien – wie MP4 oder H.264 – arbeiten mit VfW überhaupt nicht zusammen.
Um es ganz unverblümt zu sagen: VfW/AVI ist veraltet. Es ist höchste Zeit, diesen Klotz vom Bein der digitalen Videowelt zu entfernen und auf aktuelle Technologien zu setzen, die nicht den Einschränkungen eines zwanzig Jahre alten Frameworks unterliegen.
Alle drei Encodingwissen-Codecs (x264, Xvid, DivX) sind in einer VfW-Version zu haben. Bei x264 war das von Anfang an eine Notlösung, die der Abwärtskompatibilität dient. Außer in extrem außergewöhnlich speziellen Situationen als temporäres Zwischenformat gibt es keinerlei Grund, x264 VfW einzusetzen. VfW-verbogenes H.264 ist unüblich, potenziell inkompatibel und nur schwer in »echtes« H.264 konvertierbar. Finger weg!
Die beiden ASP-Encoder sind dagegen fest in der VfW/AVI-Welt verwurzelt. Auch ist das verbogene VfW-ASP die übliche Form, in der uns dieses Format begegnet. Für Xvid existiert mit XvidEncraw trotzdem ein Encoder für die Kommandozeile, der sowohl »echtes« als auch VfW-ASP erzeugen kann. DivX ist dagegen ausschließlich für VfW verfügbar.
Es gibt auch ein Audio-Pendant zu VfW, das sich ACM nennt. Dafür gilt das gleiche wie für VfW: es ist veraltet und problembelastet.
Das Kommandozeilen-Interface (CLI)
Die Kommandozeile wird oft auch als Eingabeaufforderung oder Konsole bezeichnet. Das Prinzip besteht darin, Befehle in Textform einzutippen und auszuführen. Es ist das Gegenmodell zur grafischen Mausoberfläche. Die grundsätzliche Bedienung der Kommandozeile zu erklären, gehört nicht ins Encodingwissen, deshalb setze ich das voraus.
Die Abkürzung CLI steht für Commandline Interface. Das ist der englische Ausdruck für Kommandozeilen-Schnittstelle.
Kommandozeilenencoder sind unabhängig von VfW und seinen Einschränkungen. Sie bringen keine grafische Oberfläche mit, sondern müssen an der Eingabeaufforderung mit den passenden Optionen aufgerufen werden. Normalerweise kümmert sich ein grafisches Encoding-Frontend darum, die nötige Kommandozeile zu erstellen. Da die Dialoge je nach Programm etwas unterschiedlich ausfallen, sehen wir uns die in den entsprechenden Frontend-Kapiteln näher an. In den folgenden CLI-Kapiteln geht es immer darum, die Befehle von Hand zusammenzustellen.
Als Übersicht und zur allgemeinen Darstellung werden Kommandozeilen meist in Syntaxschreibweise angegeben. Dadurch sehen wir auf einen Blick, welche Optionen wir in welcher Kombination verwenden dürfen. Das könnte beispielsweise so aussehen:
foo.exe
-in "<Quelle>"
-out "<Ziel>"
[-blubb]
{-foo|-bar}
[-klick|-klack]
Die Syntaxschreibweise arbeitet mit diesen Grundregeln:
- Alle Optionen, die nicht innerhalb einer eckigen oder geschweiften Klammer stehen, müssen angegeben werden. Es wäre nicht erlaubt,
-inoder-outwegzulassen. - Alle Klammern (spitze, eckige und geschweifte) sowie der senkrechte Strich sind erklärende Zeichen, die in der echten Kommandozeile niemals auftauchen.
- Die Optionen werden jeweils durch ein Leerzeichen getrennt. Genauso steht zwischen einem Parameter und dessen zugehörigem Wert ein Leerzeichen.
- Spitze Klammern (
<und>) enthalten die Beschreibung eines Parameterwerts. Die Beschreibung muss einschließlich der Klammern durch den tatsächlichen Wert ersetzt werden. In unserem Beispiel würden wir<Quelle>durch etwas wieD:\Video\Quelle.avsersetzen und hätten als Ergebnis-in "D:\Video\Quelle.avs". - Eckige Klammern (
[und]) bezeichnen optionale Parameter. Wir können ganz nach Wunsch-blubbangeben oder weglassen. - Geschweifte Klammern (
{und}) bezeichnen eine zwingende Entweder-oder-Auswahl. Die wählbaren Optionen sind durch einen senkrechten Strich (|) getrennt. Im Beispiel müssen wir zwingend entweder-foooder-barangeben. Beide Optionen gleichzeitig sind verboten, genauso wie beide wegzulassen. Es könnten auch mehr als zwei Optionen in der Klammer stehen, was nichts ändert. Wir entscheiden uns trotzdem für genau eine davon. - Die Entweder-oder-Auswahl kann es auch in eckigen Klammern geben. Entsprechend dem optionalen Charakter der eckigen Klammer heißt das dann, wir können entweder
-klickoder-klackangeben oder beide weglassen. Beide gemeinsam anzugeben ist nicht erlaubt.
Prinzipiell können alle diese Elemente beliebig verschachtelt und aneinander gehängt werden. Die Konstruktionen, mit denen wir in den folgenden Kapiteln in Berührung kommen, bleiben aber recht übersichtlich.
Kommentare
Kommentar von AlMo | 17.2.2013
Hallo,
ich verwende nachwievor VirtualDub (v1.10.3) in Kombination mit Avisynth (v2.6.0 MT by SEt) mit x264vfw (r2200), um DVDs fürs NAS/Smartphone oder aufgenommene Videoclips vom Smartphone (die mit variabler Framerate, zwangsweise, aufgenommen wurden) in Stand-Alone kompatible x264-Videos umzuwandeln. Bisher habe ich noch keine alternative für mich gefunden, die das annähernd gleich kompatibel bewerkstelligen lässt. Hin und wieder kommt noch AviDemux zum Hilfseinsatz, aber das wars auch schon. Früher habe ich noch umständlich den AVC-Stream der AVI-Datei mit YAMB demuxed, aber seit ich heraus fand, dass mkvmerge GUI (v5.6.0) das problemlos selbst erledigt (einfach die AVI reinziehen, Audiostreams dazuholen, fertig), mach ich das nur noch so. Meine x264-Umwandlungen erfolgen mit dem Preset Medum im Level 4.1 mit meist folgenden Zusatzparametern "--keyint 250 --bframes 5 --b-adapt 2 --ref 5 --direct auto --me umh --trellis 2 --partitions all --threads 4". Die entstehende AVI ist zwar recht inkompatibel im allgemeinen, aber das ist nur ein Zwischenstadium -> kurz auf mkvmerge gezogen und als MKV abgespeichert und alles funktioniert wunderbar (am Stand-Alone, auf dem Smartphone). Probleme mit B-Frames oder Ref-Frames etc. gibt es dabei nicht.
Da aber x264vfw stets dem CLI-encoder hinterher hinkt (versionstechnisch), werde ich jetzt mal sehen, wie (un-)problematisch ich mich darauf umstellen kann und ob. Und da ich seit kurzem erst auf die Multithread-Variante von AviSynth umgestiegen und davon begeistert bin, würde ich auch gern die Thread-Aufteilung dem AviSynth-Script überlassen, statt VirtualDub da noch mitmischen zu lassen (auch wenn vDub in der aktuellsten Version dem Encoder bereits nen Extrathread neben den Filtern gibt und die Filter ebenfalls auf mehrere Threads verteilt.
Vielleicht nutze ich alles wie gehabt, bis zum letztendlichen Encode-Schritt. Denn um Qualitätseinstellungen etc. auszutesten, ist der Weg über vDub doch sehr sehr angenehm.
Wollte ich nur mal gesagt haben, da ich überhaupt nicht damit einverstanden bin - auf Grund meiner Erfahrungen - dass x264 im AVI-Container als Zwischenspeicherort schlecht geredet wird. Es klappt absolut einwandfrei!
Kommentar von AlMo | 17.2.2013
So ...
... nach längerem Ausprobieren und Herumforschen, bin ich nun nach einigen CLI-Lösungsmöglichkeiten letztendlich über LoRd_MuldeRs Tool "Simple x264 Launcher 2.08.406" gestolpert, davon begeistert und dabei hängen geblieben. Allein schon der Umstieg von x264vfw r2200 mit VirtualDub hin zu x264 r2245 per CLI hatte einen kleinen Geschwindigkeitsschub gegeben und dabei leicht geringere CPU-Auslastung gebracht. Aber der weitere Umstieg zu Mulders x264-Launcher hat die Sache nochmals spürbar beschleunigt (dadurch, dass x264 nun im 64-bit-Modus läuft, trotz 32-bit-AviSynth, und ich zudem mit meinem 2-Kern Intel Core i3-2105 bei zwei gleichzeitigen Jobs nun endlich eine 99-100%-CPU-Auslastung erreiche, statt vorher nur zwischen ca 75-95% schwankend).
Hier der Link zu seinem Tool:
http://forum.doom9.org/showthread.php?t=144140
Kommentar von Brother John | 17.2.2013
Solange AVI nicht das Endergebnis ist, bin ich schon halbwegs versöhnt. :-) Als Zwischenspeicherort mag es manchmal schon ok sein. Für deinen fall seh ich die Notwendigkeit aber nicht. Mit Lord Mulders Launcher hast du ja auch schon eine Alternative gefunden. Das Teil ist einer der leichtesten Wrapper um x264.exe. V.a. der 32/64-Bit-Übergang wird damit deutlich einfacher.
Kommentar von AlMo | 18.2.2013
Jupp, der Launcher ist ne feine Sache. Den hätte ich früher entdecken sollen. Egal. Allerdings habe ich bemerkt, dass es bei meinem System keinen Sinn macht, mehrere Jobs parallel laufen zu lassen. Zwar ist das Encoding etwas schneller, dafür sind die Ausgabedateien alledings massiv fragmentiert. Hatte mich zuerst gewundert, warum mein System plötzlich so lange braucht, bis es überhaupt einen Film abspielt, dann ging mir ein Licht auf. Hätte ich ein RAID-System, wäre das wahrscheinlich kein Thema, aber so lass ich lieber einen Job nach dem anderen laufen.
Kommentar von Jimmy | 17.3.2013
Hi... ich finde diese ganze Website sehr interessant. Zusätzlich zu neuen Informationen bekomme ich auch Hinsweise zu neuen Tools. Ich habe eine Frage: Ich verwendete in aller Regel XMedia Recode und Format Factory für das Konvertieren von Videos. Wie sind denn diese Tools einzuordnen? Sind diese Tools, die ich verwende, eignetlich verpönt in der Szene? Gibt es denn hinsichtlich der Qualität einen Unterschied zu AVISynth und VirtualDub?
Kommentar von Brother John | 18.3.2013
Hi,
Alle diese Automatiktools verleiten in der »Szene« keinen Experten zu Luftsprüngen, aber als »normaler Mensch« kann man manche davon durchaus benutzen. Es gilt zwar immernoch: je automatischer, desto schlechter im Schnitt die Ergebnisse, aber deutlich weniger krass als früher. Jedenfalls bei den guten Tools, die Unterschiede sind gewaltig. Es gibt Zeug wie Format Factory oder Super, das man höchstens mit Kneifzange und Schutzanzug anfasst, um es halbwegs sauber vom Rechner zu kriegen. XMedia Recode ist durchaus ein sinnvoller Kompromiss zwischen Qualität und Einfachheit.
Und es lohnt sich imo immer, sich trotzdem die Profi-Frontends anzuschauen. Bei denen hat sich in Sachen Automatisierung auch viel getan. Und wenn man mal Spezialanforderungen braucht, geht mit denen doch mehr. StaxRip, MeGUI und Selurs Hybrid sind die drei, die zumindest ich ständig wahrnehme.
VirtualDub ist für Schneidearbeiten und ähnliches manchmal ganz sinnvoll. Fürs reine Encoding benutzen es recht wenige: zu AVI/VfW-lastig und man kommt an der Kommandozeile einfach bequemer ans Ziel.
Kommentar von Jimmy | 20.3.2013
Hey, XMedia Recode ist auch mein Standard-Tool bislang gewesen. Es kann ziemlich viel und ermöglicht auch sehr feine Einstellungsmöglichkeiten. Ich wollte aber dann doch wissen, welche Tools zur Oberliga gehören, da mich das zunehmend interessiert hat. Habe dann MeGUI, Selurs Hybrid und Simple x264 Launcher ausprobiert. Ich muss nun sagen, dass mir Selurs Hybrid am meisten zugesagt hat. Trotz gleicher Einstellungen hat jedes Tools unterschiedliche Ergebnisse (Bildqualität und Dateigröße) produziert. Was mich aber auch wunderte, da die ganzen GUIs den selben Encoder doch benutzen... trotz unterschiedlicher GUIs werden die selben Parameter und Werte an den einen und selben Encoder übermittelt... somit sollte das Ergebnis eigentlich völlig unabhängig von einer GUI sein. Oder gibt's doch irgendwelche Unterschiede zwischen zB Hybrid und MeGUI hinsichtlich des Encodierens?
Ich merkte aber auch, dass man letzt endlich auch relativ viel Ahnung von der Materie haben muss. Viele der Tools bieten die Manipulation verschiedenster Parameter an. Somit muss man nicht nur die Parameter kennen und wissen, was sie tun, sondern eben auch, was für Werte für die jeweiligen Parameter am meisten Sinn machen. Das alles natürlich abgestimmt auf das Material, welches man encodieren will. So bin ich auch auf diese Website gestrandet :)
Was mich eigentlich noch wundert (nach allem, was ich mir nun angelesen habe), ist, warum der AVI-Container noch so häufig verwendet wird, wenn er doch überaltet ist. Die Meisten, die sich Xvids anschauen, werden doch sicherlich Abspielstationen haben, die sie mit den aktuellsten Codec-Packs ausstatten können, damit diese eben auch alles Aktuelle abspielen können. Also auch non-HD-Filme könnten doch besser unter Verwendung neuerer Container und Codecs erstellt werden. Bringt hinsichtlich Qualität und Größe reichlich Vorteile. Der MKV-Container und x264-Encoder sind ja nun auch nicht so neu...
Kommentar von Brother John | 24.3.2013
Die Frontends sind wirklich nur Frontends. Identische Konfig führt zu identischen Ergebnissen. Allerdings muss dafür die komplette Verarbeitungskette von der Quelldatei bis zum fertig encodierten Video identisch sein. So ohne Weiteres würde ich mir nicht zutrauen, das bei allen mal schnell hinzukonfigurieren. Daran dürften die Unterschiede liegen, wenn sie sich halbwegs im Rahmen halten. Ansonsten hast du dich irgendwo verklickt.
Weil er oft »gut genug« ist und noch einige alte Hardware rumstehen dürfte, die mit den neuen Formaten nicht klar kommt. Die legalen Downloadangebote, die H.264 & Co. pushen, gibt es auch noch nicht so ewig. Und die illegale Szene darf man in Sachen Video auch nie vergessen. Die spielt eine wichtige Rolle dabei, welche Formate den Leuten auf die Platten fallen. Leider reagiert sie mit gletscherhafter Geschwindigkeit auf neue Technologie. Flächendeckendes H.264 in MKV/MP4 ist für den »Normalmenschen« eine viel neuere Entwicklung als wir Videonerds das wahrnehmen.
Kommentar von Synapsenkitzler | 6.5.2013
Dank u.a. deiner ausgezeichneten Artikel steige ich jetzt von Xvid auf x264 um.
Leider steht bei deinen Artikeln kein Veröffentlichungsdatum dabei, wäre hilfreich, um die Aktualität einschätzen zu können.
Was ist mit x264vfw, siehe http://sourceforge.net/projects/x264vfw/ ?
"x264vfw ist eine VfW-Version (Video for Windows) des bekannten x264-Encoders mit ffh264-Decoder aus dem FFmpeg-Projekt"
Aktuelle Version heute (6. Mai 2013) ist vom 17. März 2013.
Wenn man mit VirtualDub arbeitet (z.B. wegen dieses absolut genialen Artikels*), ist dies wohl die einfachste Möglichkeit mit x264 encodieren zu können.
Ich könnte auch schneiden & filtern in VirtualDub, verlustlos speichern als HuffYUV. Und dann encoden mit x264.
Mir erschließt sich aber kein Vorteil daraus, außer das es länger dauert und umständlicher ist. Ich produziere ausschliesslich Videos, die dann auf Youtube veröffentlicht, und dort nach upload eh neu encodiert werden. Gerne lasse ich mich aber vom Gegenteil überzeugen.
*
7.1 Postprocessing video using VirtualDub
http://www.doom9.org/index.html?/capture/postprocessing_vdub.html
Kommentar von Brother John | 9.5.2013
x264vfw hab ich nie groß beachtet. Was ich so mitkriege, wird er halbwegs regelmäßig aktualisiert und kann auch an VfW vorbei in einem sinnvollen Container speichern.
Da du auf Youtube endest, ist es reichlich egal, welche Formate du als Zwischenprodukt für den Upload produzierst – solange Youtube damit zurecht kommt. Nur als Endprodukt sollte niemals nicht H.264 in AVI rauskommen.