x264 ist längst den Kinderschuhen entwachsen und schwer dabei, Xvid den Rang als beliebtester Open-Source-Codec abzulaufen. Und es ist tatsächlich abzusehen, dass für DVD-Backups die Tage der ASP-Codecs gezählt sind. Außerdem treibt x264 durch die starke Konzentration auf seinen Kommandozeilenencoder die Bewegung weg von VfW voran, was man nur uneingeschränkt gutheißen kann.
Für die Besprechung sämtlicher Optionen ist wieder einmal Selur zuständig. Sein Wissenswertes rund um x264 beschäftigt sich mit dem VfW-Interface, und man x264 bespricht den Kommandozeilen-Encoder. Wir beschränken uns wieder auf die fürs DVD-Backup wichtigen Einstellungen. Wie schon im Xvid-Kapitel besprechen wir zuerst alle Funktionen, die eine etwas ausführlichere Erklärung verdienen. In den anschließenden Kapiteln sind die empfohlenen Werte immer angegeben, so dass wir uns nicht unbedingt erst durch dieses doch recht umfangreiche Kapitel wühlen müssen.
Der AVC-Standard erlaubt es, einen 16 × 16 Pixel großen Makroblock in kleinere Einheiten aufzuteilen, so genannte Partitionen. Diese werden dann getrennt voneinander betrachtet, d.h. sie erhalten eigene Bewegungsvektoren und können sogar unterschiedliche Frames als Referenz verwenden. Zwar benötigt die Partitionierung einigen Speicherplatz zu Verwaltung, der allerdings durch das große Potenzial zu Erhöhung der Kompression wieder aufgewogen wird. Besonders in den Teilen des Bilds, wo viel Bewegung stattfindet, lohnen sich kleine Partitionsgrößen. Statische Bildteile profitieren dagegen nur wenig. Deshalb entscheidet x264 dynamisch, für welchen Makroblock welche Partitionierung am nützlichsten ist.
In der Konfiguration können wir einstellen, welche Partitionsgrößen x264 überhaupt berücksichtigt. Die erste Reihe im Bild mit den 8er-Größen ist für P- und B-Frames möglich. Dazu kommen im AVC High Profile die I-Frames, falls wir zusätzlich die 8×8-DCT-Transformation einschalten. Die zweite Reihe mit den 4er-Größen funktioniert für I- und P-Frames (unabhängig vom AVC-Profil), nicht aber für B-Frames.
Je kleiner die Partitionierung, desto mehr Speicherplatz benötigt die Verwaltung. Für einen unpartitionierten 16×16-Makroblock fällt etwas vereinfacht die Speicherung des Bewegungsvektors und des verwendeten Referenzframes als Overhead an. Wird der Block nun aufgeteilt, müssen diese beiden Daten für jede Partition gespeichert werden. Für die 8×8-Partitionierung bedeutet das eine Vervierfachung des Overheads. Ein vollständig in 4×4-Partitionen unterteilter Block benötigt schon 16 Mal so viel Verwaltungsspeicher. Deshalb ist ein AVC-Encoder praktisch gezwungen, die Partitionsgrößen je nach Bildinhalt zu variieren. Ansonsten wäre der Kompressionsvorteil durch den enormen Anstieg des Overheads schnell wieder zunichte gemacht.
Was heißt das nun praktisch für die Encoder-Konfiguration? Da alle wichtigen Decoder das AVC High Profile beherrschen, spricht nichts dagegen, sämtliche Partitionierungsmöglichkeiten zu aktivieren. Zwar ist damit ein enormer Geschwindigkeitsverlust verbunden, andererseits entsteht durch die dynamische Partitionierung ein riesiges Potenzial zu Verbesserung der Bewegungssuche und Bewegungskompensation. Da es sich dabei um zentrale Bestandteile des Encodingvorgangs handelt, ist die Rechenzeit gut angelegt. Ohne volle Flexibilität in der Partitionierung würden wir x264 eines wichtigen Teils seiner Kompressionseffizienz berauben. Bevor wird also die Partitionen einschränken, sollten wir immer zuerst an anderer Stelle nach Möglichkeiten zur Steigerung der Geschwindigkeit suchen.
Das Konzept der B-Frames haben wir im Kapitel über die Interframe-Kompression schon angesprochen. Hier beleuchten wir die bidirektionalen Bilder aus der Sicht von x264, denn der Encoder bietet uns die gewaltige Zahl von neun Stellschrauben zur Konfiguration.
Erst einmal wäre da die leicht verständliche Einstellung, ob überhaupt B-Frames verwendet werden sollen, und wenn ja, wie viele maximal direkt hintereinander stehen dürfen. Mit einem Maximum von zwei wäre 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. Wichtig: Die Einstellung definiert nur das Maximum. Es bedeutet nicht, dass immer genau so viele B-Frames hintereinander stehen. Lediglich können niemals mehr als das Maximum aufeinander folgen. Innerhalb dieser Grenze berechnet x264 selbst die günstigste Möglichkeit.
Diese automatische Auswahl lässt sich beeinflussen (B-Frame-Bias). Wir haben die Möglichkeit, x264 zum verstärkten B-Frame-Einsatz zu drängen oder ihn eher davon abzuhalten. Außerdem können wir dem Encoder vorschreiben, ob er bei der Entscheidung für ein B-Frame die aktuellen Gegebenheiten des Videos berücksichtigen darf (adaptive B-Frames). Und zuletzt bleibt die Einstellung, ob B-Frames selbst wieder als Referenzbilder dienen dürfen.
Für das 1-CD-Encoding sollten wir mit B-Frames nicht sparen. 5 Stück dürfen es als Maximum schon sein. Noch höher zu gehen, bringt allerdings kaum einen Qualitätsgewinn. Im Gegenteil wächst dadurch die Gefahr, dass wegen der höheren Kompression der B-Frames Artefakte sichtbar werden. 2-CD-Encodings kommen gut mit etwa 3 B-Frames aus, und für noch höhere Zielgrößen können wir auch auf 2 herunter gehen. Sie ganz zu deaktivieren, ist in der Regel nicht sinnvoll. Denn B-Frames sind ein Tool, das die Dateigröße deutlich in den Keller ziehen kann ohne die Qualität spürbar zu beeinflussen. Entsprechend groß fällt der Nachteil aus, wenn wir sie abschalten.
x264s Lust auf B-Frames benötigt normalerweise keine Anpassung. Auch sollten wir die adaptive Verteilung zulassen, da nur so B-Frames auf eine »intelligente« Art und Weise gesetzt werden können. »Intelligent« heißt, dass in langsamen Szenen mehr B-Frames auftauchen als in schnellen. Da gerade in langsamen Szenen die Bidirektionalität ihren größten Vorteil entfaltet, ist das so auch sinnvoll. Auch die B-Pyramide (B-Frames als Referenz) senkt die Geschwindigkeit nicht allzu wesentlich. Da auch der Qualitätsgewinn nicht überragend ausfällt, können wir die Funktion bei höheren Zielgrößen auch abschalten und damit der Encodingzeit ein wenig Gutes tun.
Um die Quantisierung und Bewegungssuche in B-Frames zu beeinflussen, stehen uns noch einmal fünf Optionen zur Verfügung. Eine davon betrifft die Partitionierung der Makroblocks, womit wir uns weiter oben schon beschäftigt haben. Als weiteren wichtigen Punkt haben wir den Direct Mode, der angibt, nach welchem Verfahren B-Frames komprimiert werden. Der temporale Modus verwendet zur Komprimierung die zeitlichen Änderungen zwischen den Bildern, der spatiale die räumlichen innerhalb des Frames.
Um Aus- und Überblendungen exakter zu speichern, können wir eine gewichtete Bewegungssuche verwenden, bei der die gefundenen Referenzen in einer beliebig gewichteten Mischung verwendet werden dürfen. Mit einer weiteren Option kann die Suche nach Referenzen zusätzlich erweitert werden (bidirektionale ME), was die Chance auf bessere Ergebnisse bietet, aber Geschwindigkeit kostet.
Schließlich besitzt x264 ein B-Frame-Feature namens Rate Distortion Optimization (RDO), das mit Xvids VHQ für B-Frames vergleichbar ist. Auch hier werden für die Makroblocks verschiedene Szenarien durchgerechnet und dasjenige mit der geringsten Bitanzahl ausgewählt. Allerdings benötigt diese Funktion zwingend einen der genaueren und damit langsameren Modi für die allgemeine Bewegungssuche. B-Frame-RDO ist deshalb mit deutlichen Geschwindigkeitseinbußen verbunden.
Wollen wir die beste Kompression und beste Qualität herausholen, sollten natürlich sämtliche B-Frame-Features aktiviert sein. Allerdings bremst das den Encodingvorgang deutlich aus. Eher geringen Einfluss auf die Qualität hat die gewichtete und bidirektionale Bewegungssuche, weshalb sich diese Kandidaten besonders bei höheren Zielgrößen zum Deaktivieren anbieten. B-Frame-RDO sollten wir uns dagegen möglichst gönnen, da es sich spürbar auf die Qualität auswirkt. Und um den Direct Mode müssen wir uns zum Glück nicht unbedingt kümmern, denn x264 besitzt eine Automatik, die je nach Situation selbst den zeitlichen oder räumlichen Modus wählt.
Deblocking-Filter kennen wir von Decodern, die damit beim Abspielen Blockartefakte im Bild zu übertünchen versuchen. Sowohl die Decoder von Xvid und DivX als auch ffdshow besitzen diese Funktion. x264 setzt einen Deblocking-Filter schon beim Encodieren ein, und zwar nachdem ein Bild codiert wurde, aber bevor es als Referenz für das nächste Bild dient. Dadurch kann Bild 2 mit einer Referenz arbeiten, die weniger Artefakte enthält. Das tut der Qualität gut. Der Nachteil ist die sinkende Geschwindigkeit, um zwar sowohl beim Encoding als auch beim Decoding. Denn damit Bild 2 korrekt decodiert werden kann, muss das vorangehende Bild in gefilterter Form vorliegen. Das ähnelt einem Xvid-Encoding bei dem wir gezwungen sind, beim Anschauen den Deblocking-Filter zu aktivieren.
Die Stärke des Filters wird über zwei Stellschrauben geregelt, Strength und Threshold, oder entsprechend den offiziellen technischen Bezeichnungen Alpha- und Beta-Deblocking. Der Wert 0 steht jeweils für die Standardeinstellung des Filters. Negative Werte führen zu schwächerem Deblocking, positive zu stärkerem. Ein 1-CD-Encoding verträgt etwas stärkeres Filtering, da es mehr unter Blockbildung leidet. Werte von 2 sind ein guter Ansatzpunkt. Für höhere Datenraten bietet es sich an, mit schwächeren Werten zu arbeiten (etwa –2). Erst bei äußerst hochqualitativen Encodings im Bereich einer ganzen DVD würde ich dann darüber nachdenken, den Filter ganz abzuschalten.
Natürlich ist es auch möglich, das Deblocking ganz genau abzustimmen, indem wir die Alpha- und Beta-Werte getrennt verändern. Das Thema hat *.mp4 guy im Doom9.org-Thread How To Use Mpeg4 AVC Deblocking Effectively etwas näher beleuchtet.
AVC unterstützt genauso wie MPEG-4 ASP Quantisierungsmatrizen, einschließlich Custom-Matrizen. Im Wesentlichen treffen alle Erklärungen aus dem Xvid-Kapitel auch hier zu. Der technische Hauptunterschied besteht darin, dass eine »Matrix« nicht wie bei den ASP-Encodern aus zwei Matrizen, sondern gleich aus acht Stück besteht. Die beiden Standardmatrizen sind
Benutzerdefinierte Matrizen sind noch nicht so zahlreich verfügbar wie für Xvid. Im Wesentlichen haben sich bisher Sharktooth und *.mp4 guy als AVC-Matrizenbauer hervorgetan, und zwar in den Doom9.org-Threads EQM AVC Series und Custom Matrices. Die dort geposteten Matrizen können wir einfach in einen Texteditor kopieren und so wie sie sind als reinen Text abspeichern. Meistens wird .cfg als Dateiendung verwendet.
Für eine irgendwie geartete Empfehlung habe ich zu wenig Erfahrung mit AVC-Matrizen. x264 verwendet in der Standardeinstellung jedenfalls die Flat.
MPEG-4 Part 2 ist auf ein einzelnes Bild beschränkt, das als Referenz für die Suche nach Bewegung benutzt werden darf (B-Frames auf zwei). MPEG-4 Part 10 (AVC) hat diese Beschränkung nicht mehr. Ein Bild darf auf bis zu sechzehn Referenzframes verweisen. Dadurch steigt das Potenzial enorm, eine gute Übereinstimmung in der Bewegungssuche zu finden, und je besser die Übereinstimmung, desto höher kann das Bild komprimiert werden, ohne die Qualität nach unten zu ziehen. Also sind mehrere Referenzframes eine gute Sache. Allerdings bekommen wir diesen Vorteil nicht gratis. Die Anforderung an Speicher und CPU-Leistung steigt, und zwar sowohl beim Encoding als auch beim Abspielen.
Außerdem entsteht durch die Mehrfachreferenzen ein weiteres Phänomen. Es existieren in AVC zwei verschiedene Arten von I-Frames: normale I-Frames und IDR-Frames (Kurzform für instantaneous decoding refresh). Sehen wir uns folgende Bildsequenz an: DPIP (D steht für IDR-Frame). Beide I-Frame-Typen sind vollständige Einzelbilder, d.h. sie selbst enthalten keine Referenzen auf andere Frames. Referenzen über einfache I-Frames hinweg sind aber möglich. Es wäre also einwandfrei erlaubt, dass das zweite P-Frame über das I-Frame hinweg auf das erste P-Frame referenziert. Die Konsequenz daraus ist die, dass ein einfaches I-Frame nicht als Punkt taugt, an dem wir den Film schneiden können, denn damit würden wir dem zweiten P-Frame zumindest einen Teil seiner Referenzen wegnehmen. Bildfehler am Anfang der zweiten Datei wären die Folge. Keyframes in dem Sinn, wie wir sie kennen, und damit tauglich als Schnittpunkt, sind nur IDR-Frames, denn eine Referenz über ein IDR-Frame hinweg ist nicht erlaubt.
x264 bietet uns die Möglichkeit, den minimalen und maximalen Abstand zwischen zwei IDR-Frames zu definieren. Mit den üblichen Bildraten einer DVD brauchen wir die Vorgabewerte aber kaum jemals zu verändern.