Zum Inhalt springen
Wechseln zu: Inhalt, Abkürzungen

Auflösungsregeln, Mod16 & Co.

Manchmal würden wir uns deutlich leichter tun, könnten wir die Zielauflösung des Backups ohne Einschränkungen festlegen. Das gilt ganz besonders fürs anamorphe Encoding. Leider steht dem die allgemeine Regel entgegen, dass die Zielauflösung idealerweise in beiden Dimensionen glatt durch 16 teilbar sein sollte. Woher diese Einschränkung kommt, warum sie sinnvoll ist und wann wir doch mit gutem Grund davon abweichen können, das betrachten wir in diesem Kapitel genauer.

Grund der Auflösungseinschränkung

Das Bild der DVD verwendet wie das fertige Encoding den Farbraum H YV12, der nur mit Auflösungen kompatibel ist, die horizontal und vertikal jeweils glatt durch 2 (mod2) teilbar sind. AviSynth setzt ein weiteres Limit oben drauf, das für die Praxis letztendlich relevant ist: horizontal mod4, vertikal mod2. Das wäre noch keine besonders erwähnenswerte Einschränkung, doch einen Schritt weiter im Backupprozess kommt der Encoder ins Spiel. Die Bewegungssuche und Bewegungskompensierung aller MPEG-4-Encoder arbeitet nicht mit einzelnen Pixeln, um die Rechenzeit in einem erträglichen Rahmen zu halten. Stattdessen kommen Makroblocks H zum Einsatz, die eine Fläche von 16×16 Pixeln zu einer Einheit zusammenfassen. Für einen Encoder besteht das Bild also aus in Zeilen und Spalten angeordneten Makroblocks. Einzelne Pixel spielen nur eine untergeordnete Rolle.

Solange das Bild horizontal und vertikal durch 16 teilbar ist (Mod16-Kriterium), funktioniert das auch bestens. Schwierigkeiten tauchen erst bei Nicht-Mod16-Auflösungen auf, wie im Bild zu sehen.

Dargestellt ist schematisch und in Originalgröße ein Einzelbild mit einer Auflösung von 248×140 Pixeln, das die rot und weiß markierten Bereiche umfasst. In der Breite passen so 15 vollständige Makroblocks nebeneinander (rot). Außerdem bleiben am rechten Rand 8 überschüssige Pixel stehen (weiß), die keinen vollständigen Block mehr ergeben. In der Höhe sieht die Situation ähnlich aus mit 8 vollständigen Blocks und 12 überschüssigen Pixeln.

Für den weißen Überschussbereich muss sich der Encoder etwas einfallen lassen, da er mit unvollständigen Makroblocks nicht arbeiten kann. Die Lösung besteht darin, die Auflösung intern auf den nächsten vollen Makroblock zu vergrößern (256×144) und das neue Stück (grauer Bereich) mit Pseudo-Bildinformationen aufzufüllen. Beim Abspielen wird das erweiterte Stück Bild vom Decoder wieder abgeschnitten, so dass man beim Anschauen von der ganzen Sache nichts mitbekommt.

Mod16-Regel und Alternativen

Damit dürfte klar sein, woher die Mod16-Regel stammt. Wir ersparen dem Encoder das Erweitern und Auffüllen des Bildes und verhindern so eine geringere Encodingeffizienz, was im 1-Pass-Verfahren zu einer größeren Datei und bei 2-Pass zu niedrigerer Qualität führen würde. Schließlich muss bei Nicht-Mod16-Auflösungen intern ein größeres Bild encodiert werden, was unweigerlich einen kleinen Teil der Bitrate für die Codierung unnützer Informationen verbrät.

Übrigens: Die Bezeichnung »Mod16« stammt von der mathematischen Modulo-Funktion, die oft mit mod abgekürzt wird und mit der man auf die glatte Teilbarkeit einer Zahl testen kann.

Für ein klassisches Encoding mit quadratischen Pixeln stellt mod16 kein Problem dar. Mit Cropping und Resizing haben wir genug Spielraum, um die Bildverzerrung H wegen der eingeschränkten Auflösungswahl vernachlässigbar klein zu halten. Kritischer ist anamorphes MPEG-4 H, wo das Resizing wegfällt. Oft bringt uns das in die Situation, beim Cropping entweder

Beides ist schlecht. Im gar nicht so seltenen ungünstigen Fall verlieren wir an jedem Rand zehn oder mehr Pixel, womit durchaus 5% oder mehr an Bildfläche verloren gehen können. Auch wenn ganz am Bildrand selten wichtige Dinge passieren, ist das ein zu hoher Wert. Schwarze Balken stehen zu lassen, macht die Sache nicht besser. Zwar bleibt das Bild vollständig intakt, allerdings kostet die harte Kante zwischen Bild und Balken spürbar Encodingeffizienz – und das heißt sinkende Qualität oder eine größere Zieldatei (vgl. das Cropping-Kapitel).

Um uns aus dieser Zwickmühle zu befreien, schneiden wir doch ins Bild hinein, beschränken das verlorene Stück aber auf ein paar unkritische wenige Pixelreihen, indem wir das Mod16-Kriterium aufweichen. D.h. wir wählen eine Auflösung, die in einer oder beiden Dimensionen nicht mehr glatt durch 16 teilbar ist.

Zwar drückt eine Nicht-Mod16-Auflösung auf die Effizienz des Encoders, allerdings weniger als würden wir ein Stück Balken stehen lassen. Der Encoder füllt das intern erweiterte Bild nämlich nicht mit schwarz auf, eben wegen des Problems des harten Übergangs zum eigentlichen Bild. Die Füllung besteht stattdessen aus Pseudo-Bild. Die einfachste und am wenigsten rechenintensive Methode ist, die letzte Pixelreihe des echten Bildes zu wiederholen. Damit hat der Encoder den harten Übergang vermieden und mit ein wenig Glück sogar Informationen generiert, die sich für eine effiziente Bewegungssuche gut eignen.

Alles in allem ist nicht-mod16 das geringere Übel als überstehende Balken. Das heißt auch, dass wir ganz genau darauf achten müssen, wirklich sämtliche Balken vollständig abzuschneiden, damit der Encoder beim internen Auffüllen den Balken nicht wieder herstellt.

Höhe des Effizienzverlusts

Um den Effizienzverlust möglichst gering zu halten, sollten wir eine Auflösung wählen, die so dicht wie möglich unter Mod16 liegt. Denn dann muss der Encoder nur wenige Zeilen ergänzen und der Effizienzverlust bleibt gering. Theoretisch jedenfalls. Praktisch besteht ein deutlicher Unterschied zwischen ASP-Encodern (Xvid, DivX) und AVC-Encodern (x264).

Die folgende Abbildung stellt den Bereich zwischen zwei benachbarten Mod16-Auflösungen dar; links die kleinere, rechts die größere. Der farbige Balken zeigt den Effizienzverlust für MPEG-4 ASP. Grün steht für einen geringen Verlust, gelb für einen moderaten und rot für einen erhöhten Verlust.

rot: grün: mod16; rot: mod16+2, +4, +6; gelb: mod8, mod16–6; grün: mod16–4, –2, mod16

Wir sehen deutlich, dass die Theorie stimmt. Je dichter unter Mod16 die Auflösung liegt, desto weniger Effizienz geht verloren. Das Verhalten ist mit Xvid ausführlich getestet. Auch ist davon auszugehen, dass sich DivX nicht wesentlich anders verhält. Drei Punkte merken wir uns:

Der Zusammenhang zwischen Effizienzverlust und geringerer sichtbarer Qualität ist nie getestet worden. Klar ist jedenfalls, dass wir uns beim Mod16-Thema mit einem Detailproblem herumschlagen. D.h. es kann unter Umständen sichtbare Auswirkungen geben, die aber sehr gering bleiben sollten. Auch im tiefroten Bereich müssen wir absolut nicht mit einem extrem viel schlechteren Ergebnis rechnen.

Die Situation für MPEG-4 AVC (H.264) sieht etwas anders aus. Wie oben stellt die folgende Abbildung den Bereich zwischen zwei benachbarten Mod16-Auflösungen dar.

grün: mod16 links, mod16 rechts, mod 2–; alles andere gelb

Die Verteilung der Farben ergibt sich aus einem Test mit x264. Die Ergebnisse waren dabei viel weniger klar und konsistent als mit Xvid. Trotzdem können wir Folgendes festhalten:

Der Effizienzverlust fällt insgesamt geringer aus als bei Xvid. Deswegen gibt es auch keine Auflösung, die wir auf jeden Fall meiden sollten.

Weiterführende Links