Keine Angst vor der Kommandozeile. Optionen einzutippen ist auch nichts anderes als grafisch Mausklicks zu setzen. Wirklich wichtig ist beide Male, zu wissen, welche Einstellung in welcher Situation günstig ist. Damit beschäftigen wir uns ausführlich in diesem Kapitel. Damit alle Kommandozeilen so wie dargestellt funktionieren, ist mindestens x264 Revision 996 nötig.
Niemals dürfen wir dabei vergessen, dass es beim Videoencoding nur wenige absolute Regeln gibt. Mit einem handfesten Grund können wir von jeder Einstellung abweichen, und wenn sie noch so stark empfohlen ist. Gerade als Einsteiger wird man kaum solche Gründe finden, doch ist es eine gute Idee, schon von Anfang an im Kopf zu behalten, dass keine der nun folgenden Empfehlungen absolut in Stein gemeißelt ist.
Je nachdem, ob wir ein 2-Pass- oder 1-Pass-Encoding durchführen, müssen wir mit x264 anders umgehen. Was die beiden Encodingmethoden tun und wann welche davon angebracht ist, haben wir uns schon im Kapitel Encodingmethoden angesehen.
Ein 2-Pass-Encoding mit x264 erfordert auch zwei Befehle. Zuerst wird x264.exe mit den Optionen für den 1st Pass aufgerufen, anschließend erneut mit den Optionen für den 2nd Pass. Den grundlegenden Aufbau der beiden Kommandozeilen sehen wir uns jetzt an, zunächst den 1st Pass. In welcher Reihenfolge die Parameter in der Kommandozeile auftauchen, ist egal. Wir halten uns nur der Übersichtlichkeit halber an ein festes Schema.
x264.exe [Optionen] --pass 1 --bitrate <Zielbitrate in kbit/s> --progress --no-ssim --no-psnr --stats "<Statistikdatei>" --output NUL "<Quelldatei>"
Für den ersten Durchlauf füttern wir x264 mit sämtlichen Encoderoptionen, die wir uns weiter unten genauer ansehen. Anschließend definieren wir mit --pass 1
den ersten Encodingdurchgang. Es folgt die Angabe der Videobitrate in kbit/s. Dabei handelt es sich um die Bitrate für die reine Videospur, also Gesamtgröße abzüglich Audiospuren und Untertitelspuren, abzüglich Containeroverhead. Da wir wegen des Overheads einen größeren Exkurs in die technischen Tiefen der einzelnen Container einlegen müssten, sparen wir uns die manuelle Berechnung. Diese Arbeit übernimmt das Encoding-Frontend.
Mit --progress
aktivieren wir die Fortschrittsanzeige des Encoders und schalten dann mit --no-ssim
und --no-psnr
die Berechnung von SSIM und PSNR ab. Für Tests sind diese Werte oft nützlich, bei einem normalen Backup bremsen sie aber nur das Encoding.
Die Option --stats
legt den Namen der Statistikdatei fest, in der die Informationen aus dem 1st Pass gespeichert werden. Dann folgt mit --output
die Angabe der Zieldatei. Da wir beim ersten Durchgang noch keine Videodatei erzeugen wollen, x264 es aber nicht erlaubt, die Option wegzulassen, schicken wir mit --output NUL
das erzeugte Video ins Datennirvana. Abschließend geben wir die Quelldatei (das AviSynth-Skript) an, die ohne spezielle Option ganz am Ende der Kommandozeile steht.
Ist der 1st Pass beendet, starten wir den 2nd Pass, der die Zieldatei erzeugt.
x264.exe [Optionen] --pass 3 --bitrate <Zielbitrate in kbit/s> --sar <PAR> --progress --no-ssim --no-psnr --stats "<Statistikdatei>" --output "<Zieldatei>" "<Quelldatei>"
Die Grundstruktur für den 2nd Pass ähnelt dem 1st Pass. Die Angaben zur Quelldatei, Statistikdatei und Bitrate müssen identisch zum 1st Pass sein! Fett markierte Bestandteile der Kommandozeile stehen für zusätzliche oder geänderte Optionen.
Mit der Option --pass 3
führen wir den 2nd Pass durch, in dem anhand der Daten aus der Statistikdatei das Zielvideo erstellt und auf die gewünschte Größe getrimmt wird.
x264 unterstützt beliebig viele Encodingdurchgänge. Wir beschränken uns jedoch auf die gewohnten zwei, da die geringe mögliche Qualitätssteigerung zusätzlicher Passes den enormen Zeitaufwand nicht wert ist. --pass 3
sorgt aber trotzdem dafür, dass die im 1st Pass erstellte Statistikdatei aktualisiert wird. So steht uns immer die Tür zu weiteren Durchgängen offen, falls das in einem extremen Ausnahmefall doch einmal nötig sein sollte.
Mit der Option --sar
legen wir anschließend das Pixel Aspect Ratio des Zielvideos fest. Das entspricht dem Setzen des AR-Flags, von dem im Anamorph-Kapitel die Rede ist. Für ein klassisches Encoding mit quadratischen Pixeln gilt immer --sar 1:1
, oder wir lassen die Option ganz weg.
Die Zieldatei ist diesmal ein echter Dateiname. Die Dateiendung legt fest, welches Format verwendet wird. Je nach gewünschtem Container für den fertigen Film verwenden wir entweder .mp4
für MP4 oder .mkv
für Matroska. Der AVI-Container ist nicht mit x264.exe kompatibel.
Die Encoderoptionen am Anfang der Kommandozeile sind grundsätzlich für alle Passes identisch. Nur ganz bestimmte Abweichungen für den 1st Pass sind möglich, um die Geschwindigkeit zu erhöhen. Weiter unten mehr dazu.
Das Single-Pass-Verfahren benötigt eine ähnliche Kommandozeile. Hauptunterschied ist der, dass wir x264 nur einmal aufrufen, denn der Encoder erstellt ja sofort die Zieldatei. Die einzig sinnvolle Wahl fürs 1-Pass-DVD-Backup ist der CRF-Modus, der so aussieht:
x264.exe [Optionen] --crf <nominaler Quant> --sar <PAR> --progress --no-ssim --no-psnr --output "<Zieldatei>" "<Quelldatei>"
Die Angaben zu Bitrate (--bitrate
), Nummer des Durchgangs (--pass
) und Statistikdatei (--stats
) fallen weg, da sie beim CRF-Verfahren keine Bedeutung haben. Stattdessen verwenden wir die Option --crf
, mit der wir den gewünschten nominalen Quantizer – d.h. das Qualitätsniveau – angeben.
Um ein wenig mehr Gefühl für x264 zu bekommen, betrachten wir eine Beispielkonfiguration für ein qualitativ hochwertiges DVD-Backup auf einem schnellen Computer. D.h. wir müssen keine zu großen Kompromisse zu Lasten der Qualität/Größe eingehen, um die Encoding-Geschwindigkeit in einem sinnvollen Rahmen zu halten.
Zunächst sehen wir uns die Kommandozeilen fürs 2-Pass-Encoding an. Die Bitrate ist natürlich nur ein Platzhalter und muss für jeden Film einzeln angepasst werden, um die gewünschte Zielgröße zu erreichen. Wir verwenden das Setup für den schnellen First Pass, das wir uns etwas weiter unten genauer ansehen. Sämtliche Parameter sind mit ihrer Beschreibung in der Kommandozeilen-Referenz (nächstes Kapitel) verlinkt. Die wichtigsten Optionen sprechen wir weiter unten in diesem Kapitel noch einmal genauer an.
x264.exe
--bframes 5
--b-adapt 2
--direct auto
--ref 1
--deblock 0:-1
--partitions none
--me dia
--subme 2
--pass 1
--bitrate 2500
--progress
--no-ssim
--no-psnr
--stats "D:\x264.stats"
--output NUL
"D:\Quelle.avs"
x264.exe
--bframes 5
--b-adapt 2
--b-pyramid
--weightb
--direct auto
--ref 6
--deblock 0:-1
--partitions p8x8,b8x8,i8x8,i4x4
--8x8dct
--me umh
--subme 7
--mixed-refs
--aq-mode 1
--aq-strength 1.0
--psy-rd 1.0:0.5
--trellis 1
--sar 16:11
--pass 2
--bitrate 2500
--progress
--no-ssim
--no-psnr
--stats "D:\x264.stats"
--output "D:\Zielvideo.mkv"
"D:\Quelle.avs"
Speichern wir auf Festplatte, ist die exakte Zielgröße nicht so wichtig. Das Beispiel als CRF-Encoding könnte wie im Folgenden aussehen.
x264.exe
--bframes 5
--b-adapt 2
--b-pyramid
--weightb
--direct auto
--ref 6
--deblock 0:-1
--partitions p8x8,b8x8,i8x8,i4x4
--8x8dct
--me umh
--subme 7
--mixed-refs
--aq-mode 1
--aq-strength 1.0
--psy-rd 1.0:0.5
--trellis 1
--crf 20
--sar 16:11
--progress
--no-ssim
--no-psnr
--output "D:\Zielvideo.mkv"
"D:\Quelle.avs"
Genaueres zum Einsatz von CRF steht im x264-Technikkapitel. Und so sieht x264 aus, wenn er arbeitet:
Dieser Abschnitt ist ausschließlich fürs 2-Pass-Encoding relevant. Wenn wir Xvid kennen, sind wir es gewohnt, dass der 1st Pass deutlich schneller abläuft als der 2nd Pass. Auch StaxRip und MeGUI kennen einen schnellen 1st Pass für x264. Erreicht wird diese hohe Geschwindigkeit dadurch, dass einige Optionen abgeschaltet werden, die das Ergebnis des ersten Durchgangs nicht oder nur unwesentlich beeinflussen.
x264 bietet keine Möglichkeit an, den »Turbo-Modus« mit einem einzelnen Schalter zu aktivieren. Wir müssen also selbst entscheiden, welche Optionen wir verändern wollen und welche nicht. Hier sind die nötigen Einstellungen:
--me dia
--subme 2
--ref 1
--partitions none
--trellis 0
--8x8dct
--weightb
--mixed-refs
--no-fast-pskip
Die Grundregel für einen schnellen 1st Pass lautet: Alle Einstellungen, die die Entscheidung des Encoders für einen bestimmten Frametyp (I, P, B) beeinflussen, sind tabu, denn wenn die Frametyp-Verteilung für eine Konfiguration optimiert wird, die in den nachfolgenden Durchgängen nicht mehr gilt, sinkt die Genauigkeit der 1st-Pass-Analyse schnell auf ein nicht mehr akzeptables Niveau. Das bedeutet deutliche Qualitätseinbußen. Natürlich ist ein beschleunigter 1st Pass so oder so nicht verlustlos zu haben, da die höhere Geschwindigkeit immer auf Kosten der Genauigkeit geht. Doch vorsichtig konfiguriert, bleiben die Einbußen so winzig, dass sie die Qualität nicht sichtbar verschlechtern. Dafür dürfen wir uns über eine deutlich kürzere Encodingzeit freuen.
Ob für hohe oder niedrige Zielgrößen, der Turbo-Modus ist immer sinnvoll; allerdings nur im 1st Pass. Alle weiteren Durchgänge müssen mit allen Optionen in ihrer endgültigen Konfiguration durchgeführt werden.
Vielleicht der zentrale Bestandteil des Encodingvorgangs ist die Suche nach Bewegung im Bild. Entsprechend wichtig ist die Konfiguration der damit zusammenhängenden Optionen. --me
steuert den Teil der Suche, der mit einer Genauigkeit von einem ganzen Pixel abläuft. --subme
ist für die Subpixel-Suche mit einer Genauigkeit bis zu einem Viertel Pixel (QPel) zuständig.
Bei beiden Optionen müssen wir wie üblich zwischen Geschwindigkeit einseits und Qualität (bei 2-Pass) bzw. Dateigröße (bei CRF) andererseits abwägen. Höhere Einstellungen benötigen oft massiv mehr CPU-Leistung, wirken sich aber ebenfalls deutlich auf Qualität/Größe aus.
Für die Vollpixel-Bewegungssuche (--me
) können wir aus fünf Algorithmen wählen.
dia
= diamantförmige Suche mit Radius 1hex
= hexagonale Suche mit Radius 2umh
= ungerade Multihex-Sucheesa
= erschöpfende Suchetesa
= erschöpfende Hadamard-SucheVon oben nach unten werden die Suchergebnisse immer besser und die Geschwindigkeit sinkt. Der beste Kompromiss auf aktuellen Rechner dürfte --me umh
sein. Auf jeden Fall vermeiden sollten wir dia
, da der Geschwindigkeitsgewinn die schlechteren Ergebnisse nicht aufwiegt (Ausnahme: schneller 1st Pass). Umgekehrt sind esa
und besonders tesa
zu langsam.
Bevor wir auf eine höhere Stufe bei der Vollpixel-Suche wechseln, sollten wir immer zunächst die Subpixel-Bewegungssuche (--subme
) ausreizen. Aus folgenden Werten können wir wählen:
1
–5
= außerhalb des schnellen 1st Pass wenig interessant6
= RDO für I- und P-Frames7
= RDO für alle Frames8
= wie 7
, zusätzlich verfeinerte RDO für I- und P-Frames9
= wie 7
, zusätzlich verfeinerte RDO für alle FramesAußer für den schnellen 1st Pass sind niedrigere Werte als 5
uninteressant. Als Standardwert verwendet x264 --subme 6
. Wenn Qualität die Hauptrolle spielt, sollten wir jedoch RDO auch für B-Frames aktivieren, d.h. mindestens --subme 7
nutzen.
Qualität/Größe | normalerweise: --me umh --subme 7 für Power-CPUs: --me umh --subme 9
|
---|---|
Geschwindigkeit | --me hex --subme 6
|
B-Frames stellen ebenfalls ein zentrales Element für ein effizientes Encoding dar, das wir im Grundlagenkapitel zur Interframe-Kompression schon angesprochen haben. Die beiden großen Stellschrauben sind die maximal erlaubte Anzahl an direkt aufeinander folgenden B-Frames (--bframes
) und der Algorithmus, nach dem x264 B-Frames verteilt (--b-adapt
).
Die maximale Anzahl bedeutet nicht, dass immer so viele B-Frames direkt hintereinander stehen. Die Option legt nur fest, dass es niemals mehr als die angegebene Zahl sein kann. Innerhalb dieser Grenze berechnet x264 selbst die beste Verteilung. Mit einem Maximum von zwei wäre also höchstens eine solche Bildsequenz aus I-Frames, P-Frames und B-Frames möglich: IPBBP, bei maximal drei B-Frames wäre es dann IPBBBP usw.
Auf jeden Fall sollten wir den neuen, intelligenteren Verteilungsalgorithmus verwenden. Der hat allerdings den Nachteil, dass er um so langsamer arbeitet je höher das B-Frame-Maximum gesetzt ist. x264 freie Hand zu lassen (also ein Maximum von 16), ist deswegen nicht besonders sinnvoll. Mit halbwegs normalen Filmen kommen so oder so kaum jemals mehr als Dreier- oder Vierer-B-Frame-Reihen vor. Wir können also je nach CPU-Leistung eher auf Nummer sicher gehen oder eine etwas engere Begrenzung setzen.
Die restlichen B-Frame-Optionen sind weniger entscheidend. Besonders mit der B-Pyramide haben wir uns schon ausführlich im x264-Technikkapiel beschäftigt. Alle Optionen werden auch in der Referenz noch einmal kurz erklärt.
Qualität/Größe | --b-adapt 2 --bframes 5 --b-pyramid --weightb --direct auto |
---|---|
Geschwindigkeit | --b-adapt 2 --bframes 3 --b-pyramid --direct auto |
Im x264-Technikkapitel haben wir schon gelernt, dass H.264 gleich mehrere Frames als Referenzbilder zulässt. Deswegen stellt sich die Frage, wie viele wir zulassen sollten. Denn wenn der Encoder in vielen Bildern nach guten Referenzen suchen darf, steigt zwar einerseits die Chance auf einen besonders guten Treffer; andererseits bricht die Encoding-Geschwindigkeit massiv ein. Es gilt also wieder einmal abzuwägen.
Wie schon bei den B-Frames definiert die erlaube Anzahl (--ref
) nur ein Maximum, das der Encoder nicht überschreiten darf aber jederzeit unterschreiten kann. Mehr als 16 Referenzbilder verbietet der H.264-Standard. In der Praxis nutzt x264 üblicherweise etwa 3 bis 5. Eine sinnvolle Einstellung liegt deshalb ebenfalls in diesem Bereich.
Qualität/Größe | --ref 6 |
---|---|
Geschwindigkeit | --ref 3 |
Was psychovisuelle Methoden sind, haben wir uns schon im Kapitel Entscheidungsfindung im Encoder angesehen. x264 verwendet Psyvis an zwei Stellen.
--aq-mode
und --aq-strength
gesteuert wird. Mit den Standardeinstellungen sind wir meistens gut bedient.Lange Zeit war ein zu glattes, rauscharmes Bild eines der größten Probleme von x264, dass sich auch mit hoher Bitrate nicht immer komplett lösen ließ. Erst mit den Psyvis wurde es nach und nach möglich, x264 für rauschige Videos fit zu machen.
Qualität/Größe | --aq-mode 1 --aq-strength 1.0 --psy-rd 1.0:0.5 --trellis 2 |
---|---|
Geschwindigkeit | --aq-mode 1 --aq-strength 1.0 --psy-rd 1.0:0.0 --trellis 0 |