H.264 weist einige deutliche Unterschiede und Neuerungen dem älteren MPEG-4 Visual gegenüber auf. In diesem Kapitel betrachten wir die neuen und besonders wichtigen Funktionen, die eine ausführlichere Erklärung verdienen. Im anschließenden Kapitel zur Encoder-Konfiguration sind die hier empfohlenen Werte immer angegeben, so dass wir uns nicht unbedingt erst durch dieses doch recht umfangreiche Kapitel wühlen müssen.
MPEG-4 Visual definiert für jedes P-Frame genau ein Bild, das als Referenz für die Suche nach Bewegung benutzt werden darf, und zwar das direkt vorangehende I/P-Frame. MPEG-4 AVC hat diese Beschränkung nicht mehr. Ein P-Frame 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:
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 Frame P4 über das I-Frame hinweg auf P2 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 P4 zumindest einen Teil seiner Referenzen wegnehmen. Bildfehler am Anfang der zweiten Datei wären die Folge. Keyframes in dem Sinn, wie wir sie kennen, sind nur IDR-Frames, denn eine Referenz über ein IDR-Frame hinweg ist nicht erlaubt. P4 darf also niemals auf P1 oder noch frühere Frames verweisen. Das heißt auch, dass fürs Springen und Schneiden nur IDR-Frames relevant sind und wir einfache I-Frames genauso wie P- und B-Frames behandeln müssen.
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.
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 Bewegungskompensierung. 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 eine gewaltige Zahl von Stellschrauben zur Konfiguration.
Drei Optionen sind dafür zuständig, die Anzahl der B-Frames und ihre Verteilung im Film festzulegen.
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. 2-CD-Encodings kommen gut mit etwa 3 B-Frames aus, und für noch höhere Zielgrößen können wir evtl. 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 auf jeden Fall zulassen.
Um die Quantisierung und Bewegungssuche in B-Frames zu beeinflussen, stehen uns noch einmal sechs Optionen zur Verfügung. Eine davon betrifft die Partitionierung der Makroblocks, womit wir uns weiter oben schon beschäftigt haben. Die restlichen Einstellungen besprechen wir im Folgenden. Bis auf die letzte Option (RDO) geht es immer darum, reine Verbesserungen zu erreichen, d.h. die Qualität soll durch diese Tools ohne Nebenwirkung steigen.
Die B-Frame-Pyramide beeinflusst die erlaubten Referenzframes. Ist die Funktion abgeschaltet, sieht die Suche nach Referenzen wie in dieser Abbildung aus:
Ein B-Frame darf kein anderes B-Frame als Referenz verwenden, sondern immer nur die vorangehenden oder folgenden I/P-Frames. B2 darf also auf P1 und P2 verweisen, nicht aber auf B1 oder B3. Das ist der klassische Modus, wie ihn auch Xvid und alle anderen ASP-Codecs verwenden. Allerdings lässt sich mit der B-Pyramide die Effizienz noch steigern. Das sieht dann so aus:
B-Frames dürfen jetzt sowohl die umliegenden I/P-Frames als auch schon vorhandene B-Frames als Referenz nutzen. B2 kann also weiterhin auf P1 und P2 verweisen, aber auch auf B1. Eine Referenz auf zukünftige B-Frames (B3) ist nicht möglich, da B3 noch gar nicht existiert, wenn B2 encodiert wird.
Ob wir die ganzen Funktionen aktivieren, hängt mit Ausnahme von RDO vor allem davon ab, ob wir uns die zusätzliche Encodingzeit gönnen wollen. Ich würde den Direct-Modus auf automatisch stellen, um x264 die richtige Entscheidung zu überlassen, und die anderen Optionen aktivieren, denn Qualität geht vor Geschwindigkeit.
Anders sieht die Sache bei RDO aus. Genau wie bei Xvids VHQ gilt hier die Empfehlung, bei hochkomprimierten (z.B. 1 CD) Encodings RDO zu aktivieren, weil davon die Qualität profitiert. Der Bremseffekt ist allerdings nicht zu verachten, denn RDO benötigt nicht nur selbst einige Rechenzeit, sondern verlangt zusätzlich noch einen der rechenintensiveren Modi bei der Subpixel-Bewegungssuche. Sanft komprimierte HQ-Backups mit hoher Zielgröße sind dagegen ohne RDO i.d.R. besser bedient, da wir uns in solchen Situationen kaum mit einem geglätteten Bild zufrieden geben, sondern auch diejenigen feinen Details erhalten wollen, die RDO gerne entfernt.
Deblocking-Filter kennen wir möglicherweise 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. Der H.264-Standard definiert einen Deblocker, der schon während des Encodings zum Einsatz kommt und damit keine beliebig zuschaltbare Zusatzfunktion ist, sondern ein Bestandteil der Encoding-Konfiguration.
Entsprechend dem Standard setzt x264 den Deblocking-Filter ein 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, und 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.
Sehen wir uns den folgenden (zweifach vergrößerten) Bildausschnitt an, der extrem stark komprimiert wurde.
Das linke Bild ist die Version ohne Deblocker und weist deutliche Makroblock-Artefakte auf. Rechts sehen wir genau das gleiche Bild, diesmal aber mit aktivem Deblocking-Filter. Die Artefakte sind vollständig übertüncht, was i.d.R. optisch besser aussieht und sich außerdem besser als Referenzbild eignet.
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: 0:0 (die Standardwerte) oder 1:2 bietet sich an. Für sanfter komprimierte Filme bietet es sich an, mit schwächeren Werten zu arbeiten (etwa –2:–1).
Natürlich ist es auch möglich, das Deblocking ganz genau abzustimmen. Das Thema hat *.mp4 guy im Doom9.org-Thread How To Use Mpeg4 AVC Deblocking Effectively etwas näher beleuchtet. Aus diesem Thread stammen auch die obigen Empfehlungen.
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.
Vereinfacht ausgedrückt ist der Quantizer ein Faktor, der die Stärke der Kompression regelt. Hochoffiziell heißt er auch quantiser scale parameter, abgekürzt QP. Er darf je nach Konfiguration für jedes Frame oder jede Makroblockpartition verschieden sein und liegt bei MPEG-4 AVC (H.264) zwischen 1 und 51, wobei nur ganze Zahlen erlaubt sind. Je kleiner der Wert, desto sanfter die Kompression und desto besser die Qualität. Übliche QPs liegen etwa zwischen 18 und 25. QP 18 hat sich als allgemeiner Richtwert für »maximale Qualität« eingebürgert. Noch kleinere Werte vergrößern die Datei, bringen aber kaum noch oder keine sichtbaren Verbesserungen.
Beim 2-Pass-Encoding haben wir mit dem Quantizer nur indirekt zu tun, da x264 die Verteilung selbst in die Hand nimmt, um die Zielgröße zu treffen. Beim 1-Pass-Encoding setzen wir den QP dagegen selbst. x264 unterstützt zwei Verfahren: das schon von Xvid und DivX bekannte CQ-Encoding mit festem Quantizer sowie das CRF-Verfahren (constant rate factor). Etwas genauer haben wir uns damit schon im Kapitel Encodingmethoden beschäftigt. CRF ist bei weitem interessanter. Wenn nicht konkrete Gründe dagegen sprechen, sollten wir für 1-Pass-Encodings immer CRF anstatt CQ verwenden.
Für CRF wählen wir einen nominalen Quantizer für die tatsächlich sichtbare Qualität. Da es sich dabei um einen Basiswert handelt, sind auch Kommazahlen wie z.B. 20,4 erlaubt. x264 passt diesen Wert den Eigenschaften der jeweilgen Szene entsprechend an.
CRF berücksichtigt also zu einem gewissen Grad, wie das menschliche Auge arbeitet, und hat deshalb dem CQ-Verfahren gegenüber einen Qualitätsvorteil. Die Dateigröße eines CRF-Encodings bewegt sich normalerweise in der selben Region wie die eines CQ-Encodings mit dem selben Quantizer, nutzt aber den Platz effizienter.