Guten Morgen!
Ich habe endlich wieder Zeit zum Testen! Und was ich schon länger genauer klären will, ist die Sache mit der Mod16-Regel. Beim anamorphen Encoding ist man ja öfter in der Situation, dass mod16 nicht wirklich hinhaut. Aber was nehmen? Mod8, mod4? Ganz was anderes? Darum dreht sich dieser Test. Als Encoder war Xvid im Einsatz. Ich würde schätzen, dass sich DivX und die anderen ausgereiften ASP-Encoder zumindest grob ähnlich verhalten. Schließlich arbeiten sie alle nach dem selben Standard.
== Setup ==
Allgemeines
Ich habe zwei Samples in sechs verschiedenen Auflösungen getestet:
Mod16, mod8, mod4+, mod4–, mod2+, mod2–
Mod16 und mod8 sollten selbsterklärend sein. Dazu kamen mod4 und mod2 in jeweils zwei Varianten. Mod4+ bezeichnet eine Auflösung, die um 4 Pixelreihen größer ist als mod16, d.h. der Encoder muss intern 12 Pixelreihen dranpappen. Umgekehrt steht Mod4– für eine Auflösung, die um 4 Pixel kleiner ist als mod16, d.h. der Encoder muss intern 4 Pixelreihen dranpappen. Für mod2 gilt das gleiche analog.
Die Überlegung hinter dieser Aufteilung war, dass der Effizienzverlust nicht unwesentlich davon abhängig sein dürfte, wie viele Pixel intern ergänzt werden müssen. Und dann lassen sich die je zwei Varianten von mod4 und mod2 nicht mehr über einen Kamm scheren. Die Zwischenvarianten mod16+6 und mod16–6 habe ich weggelassen, um den Test nicht ganz ausufern zu lassen.
Das größte Problem bei einem solchen Test sind die notwendigerweise unterschiedlichen Auflösungen, was direkte Vergleiche trickreich werden lässt. Mehr dazu bei den Ergebnissen weiter unten. Um von Anfang an die Unterschiede klein zu halten, habe ich nur die vertikale Auflösung verändert. Horizontal war es immer mod16. Außerdem wäre anders der Mod2-Test problematisch geworden, weil YV12 horizontal mod4 benötigt.
Ok, genug Gelaber. Kommen wir zu den harten Fakten.
Sample 1
10.000 Frames einer progressiven PAL-DVD, DAR 2,35:1, hauptsächlich Dialog, statische Hintergründe, einige langsame Kameraschwenks, etwa halbe-halbe bei hellem Tageslicht und in Räumen mit künstlicher Beleuchtung.
Sample 2
10.000 Frames einer anderen progressiven PAL-DVD, DAR 2,35:1, schnelle Actionszene, Feuergefecht, teils unter Wasser, hauptsächlich mit diffusem Tageslicht beleuchtete Innenräume.
AviSynth-Skripte
Sample 1
[size=8]LoadPlugin("C:\Encoding\DGMPGDec\dgdecode.dll")MPEG2Source("E:\Video\Sample1.d2v")#natürlich jeweils nur eine Crop-ZeileCrop(8,80,-8,-80) #704x416, mod 16Crop(8,76,-8,-76) #704x424, mod 8Crop(8,78,-8,-78) #704x420, mod 4+Crop(8,82,-8,-82) #704x412, mod 4–Crop(8,78,-8,-80) #704x418, mod 2+Crop(8,82,-8,-80) #704x414, mod 2–[/size]
Sample 2
[size=8]
LoadPlugin("C:\Encoding\DGMPGDec\dgdecode.dll")
MPEG2Source("E:\Video\Sample2.d2v")
#natürlich auch hier jeweils nur eine Crop-Zeile
Crop(0,80,-0,-80) #720x416, mod 16
Crop(0,76,-0,-76) #720x424, mod 8
Crop(0,78,-0,-78) #720x420, mod 4+
Crop(0,82,-0,-82) #720x412, mod 4–
Crop(0,78,-0,-80) #720x418, mod 2+
Crop(0,82,-0,-80) #720x414, mod 2–[/size]
Encoder
Xvid 1.1.2 Koepi und Xvid_Encraw 2007-02-03
Konfiguriert nach Teegedecks HQ-58%-Preset, angepasst für CQ 3.
Zitatxvid_encraw -i "Sample 1 Mod 16.avs" -avi "Sample 1 Mod 16.avi" -cq 3 -qtype 1 -qmatrix C:\Encoding\Matrizen\SixOfNine.xcm -qpel -bquant_ratio 162 -bquant_offset 0 -zones 0,w,1,O -vhqmode 4 -bvhq -progress 25 > "Sample 1 Mod 16.stats"
== Ergebnisse ==
Hier erstmal die Verteilung der Frametypen für beide Samples. Unterschiede wegen der verschiedenen Auflösungen waren zwar vorhanden, aber nicht der Rede wert.
Sample 1
I-Frames ~1 %
P-Frames ~35 %
B-Frames ~64 %
Sample 2
I-Frames ~3 %
P-Frames ~49 %
B-Frames ~48 %
Und hier sind die richtig interessanten Zahlen (Grafiken sind auch nochmal ans Posting angehängt, damit sie nicht verloren gehen):
[Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_sample1.png]
[Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_sample2.png]
Das Mod16-Encoding dient als Referenz. Alle Abweichungen beziehen sich darauf.
Abw. A ist die reine Abweichung in der Dateigröße.
Abw. B versucht, die Verzerrung wegen der unterschiedlichen Auflösungen zu kompensieren, indem die Flächenabweichung von der Dateigrößen-Abweichung abgezogen wird, d.h. Abw. B = Abw. A – Abw. Px. Mehr dazu gleich.
Rang ist die Rangfolge der Nicht-Mod16-Auflösungen von niedrigem zu hohem Effizienzverlust, ermittelt anhand Abw. B.
== Diskussion ==
Erstmal fallen die deutlich unterschiedlichen Zahlen zwischen den beiden Samples auf. Aus den deutlich kleineren Abweichungen bei Sample 2 könnte man vermuten, dass Actionszenen besser mit nicht-mod16 zurechtkommen. Es wäre zwar sehr gewagt, das aus einem einzigen Test so zu verallgemeinern, aber man sollte das für zukünftige Tests mal im Hinterkopf behalten.
Auch interessant: Die Rangfolge ist trotz der zahlenmäßigen Unterschiede die gleiche. Mod4– und mod2– schneiden am besten ab, mod8 liegt mitten drin und mod4+ und mod2+ bilden das Schlusslicht. Das bestätigt die Vermutung vom Anfang, nämlich dass der wichtigste Einflussfaktor auf den Effizienzverlust tatsächlich die Anzahl der Pixelreihen ist, die intern ergänzt werden müssen. Es widerspricht der landläufigen Meinung, dass mod16 perfekt wäre, mod8 noch akzeptabel und alles andere zu schlecht. Und das heißt, dass ich wohl demnächst das Encodingwissen anpassen muss.
Die Rangfolge führt uns direkt zur Aussagekraft von Abw. B. Deren Berechnung unterstellt einen linearen Zusammenhang zwischen Bildfläche und Bitrate, d.h. 1% mehr Fläche = 1% mehr Bitrate, was so an und für sich erstmal Unsinn ist. Die Komplexität in einem Videobild ist ja alles andere als gleichverteilt. Gerade am Rand sollte man erwarten, dass wenig los ist und dementsprechend der Bitratenanstieg unterproportional ausfällt. D.h. meine lineare Rechnung ist eher ein Best-Case-Szenario. Deswegen solltet ihr auch nicht zu viel auf die exakten Zahlen geben – incl. der seltsamen Tatsache, dass manche Varianten sogar relativ kleiner sind als das »perfekte« mod16. Wichtig ist die Rangfolge der Mod-Varianten, was auch dem eigentlichen Sinn des Tests entspricht. In den Zahlen mag zwar ein Fehler drin sein, aber zumindest ist das ein systematischer, der die Rangfolge nicht wesentlich beeinflussen sollte. Vielleicht fällt ja jemandem auch noch eine bessere Möglichkeit ein, den Auflösungsunterschied zu kompensieren.
== Fazit ==
Der Test bietet einen ersten Eindruck, welches mod »günstig« ist, wenn mod16 mal nicht möglich ist. Mir reicht die Aussagekraft schon, um die Empfehlung »Mod16 oder alternativ mod8« umzuschmeißen. Worüber der Test nichts oder nur extrem bedingt etwas aussagt, ist die Höhe des Effizienzverlusts. Ich mag mich nur zu der Pi-mal-Daumen-Schätzung hinreißen lassen, dass zumindest bei hochqualitativen Encodings mit niedrigem Quantizer das mod der Auflösung nur eine sehr untergeordnete Rolle für die schlussendliche Qualität spielt.
Soweit erstmal von mir. Kommentare? Ideen? Vorschläge?
(Btw: Ein solcher Test mit x264 schwebt mir schon vor.)