subq: Von den Optionen, die dir erlauben, einen Kompromiss zwischen Geschwindigkeit und Qualität einzugehen, sind subq und frameref (siehe unten) gewöhnlich die bei weitem wichtigsten. Wenn du dich für die Optimierung von entweder Geschwindigkeit oder Qualität interessierst, sind diese die ersten, die du in Erwägung ziehen solltest. Bei der Dimension Geschwindigkeit, interagieren die Optionen frameref und subq ziemlich stark miteinander. Die Erfahrung zeigt, dass mit einem Referenzframe subq=5 (die Standardeinstellung) das ganze etwa 35% mehr Zeit in Anspruch nimmt als subq=1. Mit 6 Referenzframes wächst der Nachteil auf 60%. Der Effekt, den subq auf den PSNR ausübt, scheint ziemlich konstant zu sein, ungeachtet der Anzahl der Referenzframes. Typischerweise erreicht subq=5 einen 0.2-0.5 dB höheren globalen PSNR im Vergleich zu subq=1. Dies ist gewöhnlich ausreichend, um sichtbar zu werden.

subq=6 ist langsamer und führt bei erträglichen Kosten zu besserer Qualität. Im Vergleich zu subq=5 gewinnt sie gewöhnlich 0.1-0.4 dB globalen PSNR mit Geschwindigkeitseinbußen, die sich zwischen 25%-100% bewegen. Im Unterschied zu anderen Levels von subq hängt das Verhalten von subq=6 nicht sehr von frameref und me ab. Statt dessen hängt die Effektivität von subq=6 größtenteils von der Anzahl der verwendeten B-Frames ab. Im Normalgebrauch bedeutet dies, subq=6 hat einen großen Einfluss auf Geschwindigkeit und Qualität in komplexen, stark bewegten Szenen, kann aber auch einen geringen Effekt in Szenen mit wenig Bewegung haben. Beachte, dass dennoch empfohlen wird, bframes immer auf etwas anderes als null zu setzen (siehe unten).

subq=7 ist der langsamste Modus mit der höchsten Qualität. Im Vergleich zu subq=6 erreicht er normalerweise zwischen 0.01-0.05 dB Zuwachs des globalen PSNR bei Geschwindigkeitseinbußen variierend von 15%-33%. Da der Kompromiss zwischen Zeit gegenüber Qualität recht gering ist, solltest du ihn nur benutzen, wenn du jedes mögliche Bit einsparen möchtest und Encodierzeit keine Rolle spielt.

frameref: frameref ist per Voreinstellung auf 1 gesetzt, jedoch solltest du deshalb nicht darauf schließen, dass es unbedingt auf 1 gesetzt sein muss. Allein die Erhöhung von frameref auf 2 bringt rund 0.15dB PSNR mit einem Geschwindigkeitsnachteil von 5-10%; dies sieht nach einem guten Kompromiss aus. frameref=3 bringt rund 0.25dB PSNR mehr als frameref=1, was einen sichtbaren Unterschied machen sollte. frameref=3 ist rund 15% langsamer als frameref=1. Leider setzen vermindernde Rückgaben schnell ein. frameref=6 kann erwartungsgemäß nur 0.05-0.1 dB mehr als frameref=3 bei zusätzlichen 15% Geschwindigkeitsnachteil. Oberhalb frameref=6 sind die Qualitätsgewinne für gewöhnlich sehr klein (obwohl du während der ganzen Diskussion im Kopf behalten solltest, dass sie abhängig von deiner Quelle stark variieren können). In einem ziemlich typischen Fall wird frameref=12 den globalen PSNR um ein bisschen mehr als 0.02dB gegenüber frameref=6 verbessern, bei Geschwindigkeitseinbußen von 15%-20%. Bei so hohen frameref-Werten ist das wirklich einzig Gute, dass man sagen kann, dass ein weiteres Anheben dieses Wertes ziemlich sicher nie den PSNR schädigen wird, jedoch sind zusätzliche Qualitätsvorteile sogar kaum messbar, geschweige denn wahrnehmbar.

Wenn du auf Geschwindigkeit abzielst, ist ein vernünftiger Kompromiss, im ersten Durchgang niedrigere subq- und frameref-Werte zu nehmen, und sie danach im zweten Durchgang zu erhöhen. Typischerweise hat dies einen vernachlässigbar negativen Effekt auf die Encodierqualität: Du wirst womöglich unter 0.1dB PSNR verlieren, was viel zu klein für einen sichtbaren Unterschied sein sollte. Trotzdem, unterschiedliche Werte für frameref können auf verschiedene Weise die Frametypenbestimmung beeinflussen. Höchstwahrscheinlich sind dies außerordentlich seltene Fälle, willst du jedoch wirklich sicher gehen, ziehe in Betracht, ob dein Video entweder Vollbild- respektive Einblendungsmuster oder sehr große temporäre Überdeckungen enthält, was einen I-Frame erzwingen könnte. Passe frameref des ersten Durchgangs so an, dass es groß genug ist, die Dauer des Einblendungszyklus (oder der Überdeckungen) zu enthalten. Zum Beispiel, wenn die Szene zwischen zwei Bildern über eine Zeitspanne von drei Frames rückwärts und vorwärts springt, setze frameref des ersten Durchgangs auf 3 oder höher. Dieser Sachverhalt kommt vermutlich extrem selten in Videomaterial mit Live Action vor, erscheint aber manchmal bei eingefangenen Computerspiel-Sequenzen.

me: Diese Option dient der Wahl der Suchmethode der Bewegungseinschätzung. Diese Option zu verändern stellt einen überschaubaren Kompromiss zwischen Qualität und Geschwindigkeit dar. me=dia ist nur ein paar Prozent schneller als die Standardsuche, auf Kosten von unter 0.1dB globalem PSNR. Die Standardeinstellung (me=hex) ist ein angemessener Kompromiss zwischen Qualität und Geschwindigkeit. me=umh bringt ein wenig unter 0.1dB globalem PSNR, mit Geschwindigkeitsnachteil, der abhängig von frameref variiert. Bei hohen frameref-Werten (z.B. 12 oder so) ist me=umh etwa 40% langsamer als die Standardeinstellung me=hex. Mit frameref=3 fällt der Geschwindigkeitsnachteil auf 25%-30%.

me=esa verwendet eine gründliche, für die praktische Anwendung zu langsame Suche.

partitions=all: Diese Option aktiviert die Verwendung von 8x4, 4x8 und 4x4 Unterteilungen in den vorhergesagten Macroblöcken (zusätzlich zu den Standardunterteilungen). Sie zu aktivieren führt zu einem recht beständigen Geschwindigkeitsverlust von 10%-15%. Sie ist ziemlich nutzlos bei Quellen, die nur langsame Bewegungen enthalten, obwohl in manchen Quellen mit sehr viel Bewegung und vielen kleinen, sich bewegenden Objekten Zugewinne von etwa 0.1dB erwartet werden können.

bframes: Wenn du gewohnt bist, mit anderen Codecs zu encodieren, hast du womöglich empfunden, dass B-Frames nicht immer nützlich sind. Bei H.264 wurde dies geändert: es gibt neue Techniken und Blocktypen, die in B-Frames möglich sind. Für gewöhnlich kann selbst ein einfältiger Algorithmus zur Wahl der B-Frames einen signifikanten PSNR-Vorteil bringen. Es ist interessant festzustellen, dass die Anwendung von B-Frames normalerweise den zweiten Durchgang ein bisschen beschleunigt, und er kann auch eine Encodierung mit einfachem Durchgang etwas schneller machen, wenn adaptive B-Frame-Bestimmung deaktiviert ist.

Mit deaktivierter adaptiver B-Framebestimmung (nob_adapt von x264encopts) ist der optimale Wert für diese Einstellung normalerweise nicht mehr als bframes=1, andernfalls leiden Szenen mit sehr viel Bewegung darunter. Mit aktivierter adaptiver B-Framebestimmung (das Standardverhalten) ist es sicher, höhere Werte zu verwenden; der Encoder wird die Anwendung von B-Frames in Szenen reduzieren, in denen sie die Kompression schädigen könnten. Der Encoder zieht es selten vor, mehr als 3 oder 4 B-Frames zu verwenden; diese Option höher zu setzen wird einen geringen Effekt haben.

b_adapt: Beachte: Dies ist standardmäßig eingeschaltet.

Ist diese Option aktiviert, wird der Encoder einen einigermaßen schnellen Entscheidungsprozess zur Reduzierung der Anzahl B-Frames in Szenen anwenden, die nicht viel von ihnen profitieren würden. Du kannst b_bias dazu verwenden, zu optimieren wie froh der Encoder über B-Frames sein soll. Der Geschwindigkeitsnachteil adaptiver B-Frames ist gegenwärtig ziemlich bescheiden, und genauso ist der potentielle Qualitätsgewinn. Es sollte aber normalerweise nicht schaden. Beachte, dass dies nur Geschwindigkeit und Frametypenbestimmung im ersten Durchgang betrifft. b_adapt und b_bias haben keinen Effekt auf nachfolgende Durchgänge.

b_pyramid: Du kannst diese Option genauso gut aktivieren, falls du >=2 B-Frames verwendest; wie die Manpage dir sagt, erreichst du eine kleine Qualitätsverbesserung bei keinerlei Geschwindigkeitseinbuße. Beachte, dass diese Videos von libavcodec-basierten Decodern älter als etwa 5. März 2005 nicht gelesen werden können.

weight_b: In typischen Fällen gibt es nicht viel Gewinn mit dieser Option. Trotzdem, in überblendenden oder ins Schwarze übergehenden Szenen liefert die gewichtete Vorhersage ziemlich große Einsparungen bei der Bitrate. In MPEG-4 ASP wird ein Übergang ins Schwarze gewöhnlich am besten als eine Serie aufwändiger I-Frames codiert; das Verwenden einer gewichteten Vorhersage in B-Frames macht es möglich, wenigstens manche von diesen in viel kleinere B-Frames zu wandeln. Der Verlust an Encodierzeit ist minimal, da keine extra Bestimmungen vorgenommen werden müssen. Auch werden die CPU-Anforderungen des Encoders, im Gegensatz zu den Einschätzungen mancher Leute, von gewichteter Vorhersage nicht sonderlich beeinflusst, ansonsten bleibt alles gleich.

Leider hat der aktuelle Algorithmus zur adaptiven B-Frame-Bestimmung eine starke Tendenz, B-Frames während des Fadens zu verhindern. Bis sich dies ändert, kann es eine gute Idee sein, nob_adapt zu deinen x264encopts hinzuzufügen, falls du erwartest, dass Fades einen großen Effekt in deinem jeweiligen Videoclip erzeugen.

threads: Diese Option erlaubt es, mehrere Threads zu erstellen, um parallel auf mehreren CPUs zu encodieren. Du kannst die Anzahl der Threads manuell wählen oder, besser, setze threads=auto und lasse x264 erkennen, wie viele CPUs verfügbar sind, und die passende Anzahl Threads automatisch wählen. Wenn du eine Multi-Prozessor-Maschine hast, solltest du wirklich in Erwägung ziehen, dies zu benutzen, da es die Encodiergeschwindigkeit linear in der Anzahl der CPU-Kerne (ca. 94% pro CPU-Kern) erhöhen kann, bei sehr geringem Qualitätsverlust (ca. 0.005dB bei Dualprozessor, ca. 0.01dB bei einer Quad-Prozessor-Maschine).

2-pass-Encodierung: Oben wurde vorgeschlagen, immer 2-pass-Encodierung anzuwenden. Es gibt aber durchaus Gründe, dies nicht zu tun. Beispielsweise bist du, wenn du Live-TV aufnimmst und in Echtzeit encodierst, gezwungen, einen einzigen Durchgang zu verwenden. Auch ist ein Durchgang offensichtlich schneller als zwei Durchgänge; wenn du exakt die gleichen Optionen bei beiden Durchgängen anwendest, ist das Encodieren in zwei Durchgängen mindestens zweimal so langsam.

Noch gibt es sehr gute Gründe, in zwei Durchgängen zu encodieren. Zum einen ist Ratenkontrolle in einem Durchgang kein Allheilmittel. Sie trifft oft eine unvernünftige Auswahl, weil sie das große Bild nicht sehen kann. Zum Beispiel angenommen, du hast ein zwei Minuten langes Video bestehend aus zwei ausgeprägten Hälften. Die erste Hälfte besitzt eine 60 Sekunden dauernde Szene mit sehr viel Bewegung, die einzeln für sich etwa 2500kbps benötigt, um anständig auszusehen. Direkt daruffolgend kommt eine viel weniger anspruchsvolle 60 Sekunden lange Szene, die bei 300kbps gut aussieht. Angenommen du forderst in der Theorie 1400kbps an, was beiden Szenen ausreichend entgegenkommen würde. Die Ratenkontrolle in einem Durchgang wird in diesem Fall ein paar "Fehler" machen. Zuallererst wird es in beiden Segmenten 1400kbps anpeilen. Das erste Segment könnte schwer überquantisiert enden, was es unakzeptabel und unangemessen blockhaft aussehen lässt. Das zweite Segment wird schwer unterquantisiert sein; es sieht vielleicht perfekt aus, aber der Bitratenverlust dieser Perfektion wird komplett unangemessen sein. Noch schwerer vermeidbar ist das Problem am Übergang beider Szenen. Die ersten Sekunden der Hälfte mit wenig Bewegung wird enorm überquantisiert sein, weil die Ratenkontrolle noch die Art Anforderung an die Bitrate erwartet, der sie in der ersten Hälfte des Videos begegnet war. Diese "Fehlerperiode" der extrem überquantisierten Szene mit wenig Bewegung wird fürchterlich schlecht aussehen, und wird sogar weniger als die 300kbps in Anspruch nehmen als das, was sie genommen hätte, um annehmbar auszusehen. Es gibt Mittel und Wege, diese Fälle des Encodierens in einem Durchgang zu mildern, diese werden allerdingst dahin tendieren, die fehlerhaften Vorhersagen der Bitraten zu häufen.

Multipass-Ratenkontrolle kann gegenüber der eines einzigen Durchgangs enorm große Vorteile bieten. Indem sie die im ersten Encodierungsdurchlauf gesammelte Statistik verwendet, kann der Encoder mit angemessener Genauigkeit den Aufwand (in Bit) abschätzen, den das Encodieren jeden gegebenen Frames bei jedem gegebenen Quantisierer erfordert. Dies erlaubt eine viel rationalere, besser geplante Zuweisung von Bits zwischen den bithungrigen Szenen mit viel Bewegung und denen bescheidenen mit wenig Bewegung. Siehe qcomp unten für einige Ideen darüber, wie man diese Zuweisungen nach seinem Geschmack optimiert.

Darüber hinaus brauchen zwei Durchgänge zweimal so lang wie ein Durchgang. Du kannst die Optionen im ersten Durchgang auf höhere Geschwindigkeit und niedrigere Qualität optimieren. Wenn du deine Optionen geschickt wählst, kannst du einen sehr schnellen ersten Durchgang hinkriegen. Die resultierende Qualität im zweiten Durchgang wird geringfügig niedriger ausfallen, weil die Größenvorhersage weniger akkurat ist, jedoch ist die Qualitätsdifferenz normalerweise viel zu klein, um sichtbar zu sein. Versuche zum Beispiel subq=1:frameref=1 zu x264encopts des ersten Durchgangs hinzuzufügen. Verwende dann im zweiten Durchgang langsamere, hochwertigere Optionen: subq=6:frameref=15:partitions=all:me=umh

Encodierung mit drei Durchgängen? x264 bietet die Möglichkeit, eine beliebige Anzahl aufeinander folgender Durchgänge auszuführen. Wenn du pass=1 im ersten Durchgang spezifizierst, dann verwende pass=3 im nachfolgenden Durchgang, der nachfolgende Durchgang wird beides tun, die Statistik des vorhergehenden Durchgangs lesen und seine eigene Statistik schreiben. Ein zusätzlicher Durchgang, der diesem folgt, wird eine sehr gute Basis haben, von der aus er hochpräzise Vorhersagen der Framegrößen bei einem gewählten Quantisierer machen kann. In der Praxis ist der damit erzielte gesamte Qualitätsgewinn gewöhnlich nahezu null, und ziemlich wahrscheinlich resultiert ein dritter Durchgang in einem geringfügig schlechteren globalen PSNR als der Durchgang davor. In der typischen Anwendung helfen drei Durchgänge, wenn du entweder eine schleche Vorhersage der Bitraten oder schlecht aussehende Szenenübergänge beim Verwenden nur eines Durchlaufs bekommst. Dies passiert mit ziemlicher Wahrscheinlichkeit bei extrem kurzen Clips. Ebenso gibt es ein paar Spezialfälle, in denen drei (oder mehr) Durchgänge erfahrenen Nutzern dienlich sind, aber um es kurz zu machen, dieses Handbuch behandelt die Diskussion solcher speziellen Fälle nicht.

qcomp: qcomp wägt die Anzahl der für "aufwändige" Frames mit viel Bewegung vorgesehenen Bits gegen die für "weniger aufwändige" Frames mit wenig Bewegung ab. Bei einem Extrem zielt qcomp=0 auf eine echte konstante Bitrate ab. Typischerweise würde dies Szenen mit viel Bewegung vollkommen ätzend aussehen lassen, während Szenen mit wenig Bewegung womöglich absolut perfekt aussehen, jedoch öfter mehr Bitrate verwenden würden, als sie es für lediglich sehr gutes Aussehen bräuchten. Beim anderen Extrem erreicht qcomp=1 nahezu konstante Quantisierungsparameter (QP). Ein konstanter QP sieht nicht schlecht aus, die meisten Leute meinen aber, es sei vernünftiger, etwas Bitrate aus den extrem aufwändigen Szenen zu nehmen (wobei dort der Qualitätsverlust micht ganz so augenfällig ist) und sie wieder den Szenen zuzuweisen, die bei sehr guter Qualität leichter zu encodieren sind. qcomp ist per Voreinstellung auf 0.6 gesetzt, was für den Geschmack mancher Leute etwas zu langsam sein könnte (0.7-0.8 werden im Allgemeinen auch verwendet).

keyint: keyint ist einzig und allein zur Abwägung der Durchsuchbarkeit der Datei gegenüber der Codiereffiziez da. Als Standardwert ist keyint auf 250 gesetzt. In Material mit 25fps garantiert dies, auf 10 Sekunden genau suchen zu können. Wenn du meinst, es wäre wichtig und nützlich, auf 5 Sekunden genau suchen zu können, setze es auf keyint=125; dies wird der Qualität/Bitrate leicht schaden. Wenn es dir nur um Qualität geht und nicht um die Durchsuchbarkeit, kannst du viel höhere Werte setzen (vorausgesetzt du verstehst, daß es verringerte Resultate gibt, die verschwindend klein werden oder sogar gegen null gehen). Der Videostream wird nach wie vor suchbare Stellen besitzen, solange einige Szenenwechsel vorhanden sind.

deblock: Dieses Thema ist im Begriff etwas kontrovers zu geraten.

H.264 definiert eine simple Deblocking-Prozedur bei I-Blöcken, die von vorgegebenen Stärken und vom QP des strittigen Blocks abhängigen. Mit dem Standardwert werden hohe QP-Blöcke stark gefiltert, und niedrige QP-Blöcke werden überhaupt nicht entblockt. Die vom Standard definierten vorgegebenen Stärken sind mit Bedacht gewählt und die Chancen stehen sehr gut, dass sie PSNR-optimal sind, egal welches Video auch immer du zu encodieren versuchst. Der Parameter deblock erlaubt dir, Offsets festzulegen, um Deblocking-Schwellen voreinzustellen.

Viele Leute scheinen zu glauben, es sei eine gute Idee, die Stärke des Deblocking-Filters um hohe Beträge abzusenken (sagen wir -3). Dies ist jedoch meist keine gute Idee, und in den meisten Fällen verstehen Leute, die das machen, nicht viel davon wie Deblocking standardmäßig funktioniert.

Die erste und wichtigste Sache, die man über den in-loop-Deblocking-Filter wissen sollte, ist, dass die Standardschwellenwerte meistens PSNR-optimal sind. In den seltenen Fällen, in denen sie nicht optimal sind, ist das ideale Offset plus oder minus 1. Die Deblocking-Parameter durch einen höheren Betrag anzupassen garantiert meist, dem PSNR zu schaden. Das Verstärken des Filters wird mehr Details verwischen; den Filter zu schwächen wird das Auftreten von Blockeffekten erhöhen.

Es ist definitiv eine schlechte Idee, die Deblocking-Schwellenwerte herabzusetzen, falls deine Quelle eine vorwiegend niedrige räumliche Komplexität besitzt (z.B. nicht viele Details oder Rauschen). Der in-loop-Filter macht eigentlich einen exzellenten Job durch das Kaschieren auftretender Artefakte. Besitzt die Quelle eine hohe räumliche Komplexität, sind Artefakte weniger bemerkbar. Dies ist so, weil das Schwingen (ringing) dazu neigt, wie Details oder Rauschen auszusehen. Die viselle Wahrnehmung des Menschen erkennt leicht, wenn Details entfernt wurden, aber erkennt nicht so leicht, wenn Rauschen falsch dargestellt wird. Wird die Qualität subjektiv, sind Details und Rauschen etwas austauschbares. Durch das Herabsetzen der Deblocking-Filterstärke verstärkst du höchstwahrscheinlich Fehler durch Hinzufügen von Schwingungsartefakten, aber dem Auge fällt nichts auf, weil es die Artefakte mit Details verwechselt.

Dies rechtfertigt jedoch nach wie vor nicht das Herabsetzen der Deblocking-Filterstärke. Du kannst im Allgemeinen besseres Qualitätsrauschen im Postprocessing erzielen. Falls deine H.264-Encodierungen zu verschwommen oder verschmiert aussehen, versuche, mit -vf noise beim Abspielen des encodierten Films herumzuspielen. -vf noise=8a:4a sollte die meisten weichen Artefakte kaschieren. Es wird meist mit Sicherheit besser aussehen als die Resultate, die du durch einfaches Herumtüfteln mit dem Deblocking-Filter bekommen hättest.