Wie wirken sich Nicht-Mod16-Auflösungen auf die Encodereffizienz aus? Das hab ich für Xvid schon getestet, und jetzt auch für x264. Details zu den Berechnungsmethoden etc. spare ich mir, das könnt ihr im Xvid-Thread nachlesen.
== Setup ==
Allgemeines
Ich habe fünf Samples (nur Sample5 ist identisch mit dem damaligen Xvid-Sample!) in je sieben verschiedenen Auflösungen getestet:
- Mod16 (Mod16K) und die nächstgrößere Mod16 (Mod16G),
- Mod8 zwischen den beiden 16ern,
- Mod16K+4 (Mod4+) und Mod16G–4 (Mod4–),
- Mod16K+2 (Mod2+) und Mod16G–2 (Mod2–).
Das bezieht sich nur auf die vertikale Auflösung. Die horizontale Auflösung ist je Sample fix und mod16. Die schwarzen Balken sind bei sämtlichen Auflösungen vollständig abgeschnitten. Die vertikalen Makroblockgrenzen von Quelle und Ziel fallen nie aufeinander. Die horizontalen schon, allerdings dann konsistent innerhalb eines Samples.
Samples
Jeweils 10.000 Frames von progressiven Widescreen-PAL-DVDs. Keinerlei Filter im Skript außer Crop() und Trim(). Die genauen Cropping-Werte könnt ihr euch in der angehängten Textdatei ansehen.
- Sample 1: Dialog. Ziemlich statisch, etwa halbe-halbe helles Tageslicht und Räume mit künstlicher Beleuchtung.
- Sample 2: Nacht. Mischung aus richtig duster, Straßenlaternen und eher schwach beleuchteten Innenräumen. Moderate Bewegung (Autofahrt).
- Sample 3: CG-Animation. Typische pixar-artige Animation bei Tageslicht.
- Sample 4: Action. Auto-Verfolgungsjagd bei Tag mit gut Bewegung und schnellen Schnitten.
- Sample 5: Rauschen. Älteres Material aus den 70ern. Starkes Rauschen. Szene bei Sonnenschein unter freiem Himmel mit eher wenig Bewegung.
Encoding
x264.exe, rev 719 von bob0r. Folgende Kommandozeile:
x264.exe --deblock -2:-1 --bframes 3 --b-pyramid --ref 4 --qp 20 --partitions all --8x8dct --direct auto --subme 5 --deadzone-inter 10 --deadzone-intra 5 --sar 16:11 --progress --no-ssim --no-psnr -o "1-16G.264" "1-16G.avs"
Schlagt mich nicht, weil das eine oder andere Powerfeature fehlt. Die letztendlich 63 Encodings sollten nicht jahrelang dauern. Genaue Logs gibt’s im Anhang.
== Ergebnisse ==
Die Tabellen sind genauso aufgebaut wie beim Xvid-Test. OpenDocument-Tabelle im Anhang. Die Farben stellen keine Rangfolge dar, sondern damit habe ich die Gruppen markiert, die sich beim Xvid-Test herausgestellt hatten.
[Blockierte Grafik: http://brother-john.net/files/x264-modtest.png]
Die Ergebnisse sind durchwachsen. Im Großen und Ganzen kann man mit einem bisschen guten Willen wie bei Xvid den Trend zu drei Gruppen erkennen: die beiden Mod– mit den besten Ergebnisse, die beiden Mod+ sind am schlechtesten und Mod8 sitzt in der Mitte. Allerdings ist das weder besonders deutlich ausgeprägt, noch sind die Abstände besonders groß. Was sich dagegen klar sehen lässt: Mod2– gewinnt deutlich. Alle anderen Auflösungen folgen mit einigem Abstand.
Mit einer Ausnahme: ...
Rauschiges Material ist für x264 eine besondere Situation, das zeigt sich auch hier. Die Zahlen stimmen, ich habs dreimal kontrolliert. Bei Sample5 haben tatsächlich die Mod+, bei denen intern am meisten Bild ergänzt werden muss, und das ist ungünstig! ... diese beiden Auflösungen haben einen gewaltigen Effizienzgewinn produziert. HÄ??? An dem Punkt, habe ich das Rauschsample als Ausreißer aussortiert. Wer Lust dazu hat, kann das ja noch ausführlicher testen.
Der Effizienzverlust bleibt insgesamt in engen Grenzen. Die Spannen über die Auflösungen hinweg sind geringer als beim Xvid-Test, genauso wie die absoluten Zahlen. Aber vorsicht mit Überinterpretation, die Samples waren nicht die selben. Trotzdem kommt mir ein Verlust im Mittel von 1,42%, der nur bei drei Clips 2% übersteigt, als ziemlich gering vor. Für die bisherige Vermutung, dass für x264 die Auflösung wohl egal sei, ist das allerdings zu viel.
Ob eine andere Encoder-Konfig etwas ändert, dazu im nächsten Posting.
