10.5. Encodieren mit dem `x264`-Codec
Zurück | Kapitel 10. Encodieren mit MEncoder | Weiter

## 10.5. Encodieren mit dem `x264`-Codec

`x264` ist eine freie Programmbibliothek zum Encodieren von H.264/AVC-Videostreams. Bevor du mit zu encodieren beginnst, musst du MEncoder so einstellen, dass er es unterstützt.

### 10.5.1. Encodieroptionen von x264

Bitte beginne mit der Durchsicht der `x264`-Sektion von MPlayers Manpage. Diese Sektion ist als Anhang zur Manpage vorgesehen. Hier wirst du Schnellhinweise dazu finden, welche Optionen am wahrscheinlichsten die meisten Leute interessieren. Die Manpage ist knapper gehalten, aber auch vollständiger, und zeigt oft viel bessere technische Details.

#### 10.5.1.1. Einführung

Dieses Handbuch berücksichtigt zwei Hauptkategorien der Encodieroptionen:

1. Optionen, die hauptsächlich Encodierdauer gegenüber Qualität abwägen

2. Optionen, die zur Erfüllung zahlreicher persönlicher Vorlieben und spezieller Anforderungen nützlich sind

Letztendlich kannst nur du entscheiden, welche Optionen für deine Zwecke am besten geeignet sind. Die Entscheidung für die erste Klasse der Optionen ist die einfachste: Du musst nur entscheiden, ob du denkst, dass Qualitätsunterschiede Geschwindigkeitsunterschiede rechtfertigen. Für die zweite Klasse der Optionen sind die Vorzüge weitaus subjektiver, und mehr Faktoren können involviert sein. Beachte, dass manche der Optionen für "persönliche Vorlieben und spezielle Anforderungen" noch große Auswirkungen auf Geschwindigkeit oder Qualität haben können, das ist aber nicht, wozu sie primär benutzt werden. Ein paar der Optionen für "persönliche Vorlieben" können sogar Änderungen verursachen, die für manche Leute besser aussehen aber schlechter für andere.

Bevor du fortfährst, musst du verstehen, dass dieses Handbuch nur eine Qualitätsmetrik verwendet: globaler PSNR. Für eine kurze Erklärung, was PSNR ist, schau dir den Wikipedia-Artikel zu PSNR an. Globaler PSNR ist die letzte gemeldete PSNR-Nummer, wenn du die Option `psnr` in `x264encopts` einbindest. Jedesmal wenn du eine Forderung nach PSNR liest, ist eine der Annahmen hinter dieser Forderung, dass gleiche Bitraten verwendet werden.

Nahezu alle dieser Handbuchkommentare unterstellen, dass du 2-pass anwendest. Beim Vergleich der Optionen gibt es zwei Hauptgründe, 2-pass-Encodierung zu nutzen. Der erste ist, 2-pass bringt rund 1dB PSNR, was einen sehr großen Unterschied ausmacht. Der zweite ist, Optionen zu testen, indem man direkte Qualitätsvergleiche zu 1-pass-Encodierung anstellt, führt einen einen wichtigen verwirrenden Faktor ein: die Bitrate variiert bei jeder Encodierung oft signifikant. Es ist nicht immer einfach zu sagen, ob Qualitätsänderungen vorwiegend auf geänderte Optionen zurückzuführen sind oder ob sie meist essentielle, zufällige Unterschiede in der erhaltenen Bitrate reflektieren.

#### 10.5.1.2. Optionen, die primär Geschwindigkeit und Qualität betreffen

- 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.

  ### Beachte:

  Das Erhöhen von `frameref` auf unnötig hohe Werte kann und tut dies üblicherweise auch die Codiereffizienz schädigen, wenn du CABAC ausschaltest. Mit eingeschaltetem CABAC (das Standardverhalten) scheint die Möglichkeit, `frameref` "zu hoch" zu setzen, gegenwärtig zu weit entfernt um sich Sorgen zu machen, und in der Zukunft werden womöglich Optimierungen diese Möglichkeit ganz und gar ausschließen.

  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).

#### 10.5.1.3. Diverse Eigenschaften betreffende Optionen

- 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.

### 10.5.2. Beispiele für Encodieroptionen

Die folgenden Einstellungen sind Beispiele unterschiedlicher Kombinationen von Encodier-Optionen, die einen Kompromiss zwischen Geschwindigkeit und Qualität bei gleicher Zielbitrate darstellen.

All diese Encodier-Einstellungen wurden an einem Beispielvideo mit 720x448 @30000/1001 fps getestet, die Zielbitrate war 900kbps, und der Rechner war ein AMD-64 3400+ mit 2400 MHz im 64bit-Modus. Jede Encodier-Einstellung zeichnet sich durch eine gemessene Encodiergeschwindigkeit (in Frames pro Sekunde) und dem PSNR-Verlust (in dB) im Vergleich zu den "sehr hochwertigen" Einstellung aus. Bitte hab dafür Verständnis, dass du abhängig von deiner Quelle, deinem Rechnertyp und Entwicklungsfortschritten sehr unterschiedliche Resultate erhalten kannst.

Beschreibung | Encodier-Optionen | Geschwindigkeit (in fps) | Relativer PSNR-Verlust (in dB)
--- | --- | --- | ---
Sehr hohe Qualität | `subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b` | 6fps | 0dB
Hohe Qualität | `subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b` | 13fps | -0.89dB
Schnell | `subq=4:bframes=2:b_pyramid:weight_b` | 17fps | -1.48dB

Zurück | Nach oben | Weiter
10.4. Encodieren mit dem `Xvid`-Codec | Zum Anfang | 10.6. Encodieren mit der `Video for Windows` Codecfamilie