Quantisierungsexplosion im HCencoder vermeiden?

Ich habe jetzt einen etwas repräsentativeren Clip hergenommen. Und zwar habe ich aus einem Film über einen Zoobesuch einen 60-Sekunden-Kurzfilm gemacht. Darin enthalten sind sowohl ruhige Szenen als auch Szenen mit viel Bewegung (Schwenk, Wasserszene, Wasserspringbrunnen etc.). Alle Encoder enkodierten in 2 Durchgängen bei einer mittleren Bitrate von 6500 kbps (bei möglichst optimalen Einstellungen). Die Dateigrößen waren weitestgehend identisch. Alle enthaltenen 1500 Frames wurden einer Analyse unterzogen.

Die durchschnittlichen SSIM-Werte über alle 1500 Frames ergaben sich dabei wie folgt.

Cinema Craft Encoder Basic
Q in Y: 0,9386

HC
Q in Y: 0,9414

Canopus Procoder Express
Q in Y: 0,9449

QuEnc
Q in Y: 0,9439

Die Ausgabe des BitRate Viewers brachte folgendes zu Tage.

Cinema Craft Encoder Basic
[Blockierte Grafik: http://img169.imageshack.us/img169/9839/bitrateviewerccebasic0640x0390fg3.jpg]

HC
[Blockierte Grafik: http://img244.imageshack.us/img244/32/bitrateviewerhc0640x0390qa1.jpg]

Canopus Procoder Express
[Blockierte Grafik: http://img208.imageshack.us/img208/7222/bitrateviewerprocoderexpress0640x0390zu9.jpg]

QuEnc
[Blockierte Grafik: http://img144.imageshack.us/img144/7878/bitrateviewerquenc0640x0390qs9.jpg]

Eine grafische Darstellung der SSIM-Kurve habe ich wegen der besseren Lesbarkeit für jede Szene einzeln gemacht. Ich erspare mir an dieser Stelle, alle Grafiken zu veröffentlichen. Die Grafiken, in denen der HC etwas „Auffälliges“ zeigte, sind hier zu sehen. Ich habe auch die durchschnittlichen SSIM-Werte für den jeweiligen Framebereich mit angefügt, so dass man sehen kann, wie sich ein Encoder hier schlägt. Die Werte sind aber mit Vorsicht zu genießen, da sie, erstens nur einen Ausschnitt repräsentieren und, zweitens, nicht jeder Encoder mit einem I-Frame bei einer neuen Szene beginnt etc. Die kleinen Bilder in den Grafiken zeigen immer den ersten Frame der jeweiligen Szene.

SSIM-Kurve, Frame 150 bis 407, Wasserszene mit leichtem Schwenk
- Cinema Craft Encoder Basic: 0,9226
- HC: 0,9217
- Canopus Procoder Express: 0,9354
- QuEnc: 0,9190
[Blockierte Grafik: http://img214.imageshack.us/img214/1830/ssimframe0150bis0407kc8.jpg]

SSIM-Kurve, Frame 408 bis 671, langsamer gefühlvoller Schwenk
- Cinema Craft Encoder Basic: 0,9398
- HC: 0,9434
- Canopus Procoder Express: 0,9438
- QuEnc: 0,9511
[Blockierte Grafik: http://img244.imageshack.us/img244/9026/ssimframe0408bis0671ms9.jpg]

SSIM-Kurve, Frame 672 bis 821, Nahaufnahme eines Tieres mit leichtem Schwenk
- Cinema Craft Encoder Basic: 0,9478
- HC: 0,9433
- Canopus Procoder Express: 0,9575
- QuEnc: 0,9594
[Blockierte Grafik: http://img167.imageshack.us/img167/7430/ssimframe0672bis0821od5.jpg]

SSIM-Kurve, Frame 1097 bis 1146, Wasserspringbrunnen
- Cinema Craft Encoder Basic: 0,8738
- HC: 0,8858
- Canopus Procoder Express: 0,8827
- QuEnc: 0,9095
[Blockierte Grafik: http://img80.imageshack.us/img80/1754/ssimframe1097bis1146cn1.jpg]

:daumen: Hervorragende Darstellungen. Die sollten sicher helfen, Probleme in der "rate control" zu finden. Hast du hank315 im englischen doom9-Forum schon auf diesen Beitrag hier hingewiesen?

Oder wenn er dort nicht mehr so aktiv gewesen sein sollte, müsste man's vielleicht noch mal per e-Mail oder anders versuchen.

Was auf jeden Fall recht gut zu erkennen ist: Verschiedene Encoder haben unterschiedliche Strategien, die Bitrate auf I/P- und B-Frames zu verteilen. Und einige haben nur je 1 B zwischen zwei I/P (etwas unüblich für DVD-Encodierung, aber verständlich bei viel Bewegung).

Bis jetzt dachte ich eigentlich immer, der durchschnittliche SSIM-Wert (über einen gewissen Framebereich) wäre ein guter Anhaltspunkt für eine Beurteilung. Tja, wie man sich täuschen kann. Auch den Verlauf der SSIM-Kurve (über diesen Framebereich) gilt es zu berücksichtigen.

Wenn man z. B. den Framebereich von 672 bis 821 (siehe oben) nur anhand des ermittelten SSIM-Wertes begutachten würde, dann würde man (fälschlicherweise) zu der Erkenntnis gelangen, dass der HC da nicht viel schlechter als der CCE Basic ist. Beim normalen Betrachten des HC-Videos fallen die Ausreißer zu Beginn der Szene dann aber doch deutlich auf. Ab Frame 745 verbessert sich die Situation beim HC-Video dann wieder.

Hier noch mal eine Aufsplittung des untersuchten Framebereichs. Hier kann man an den Zahlen sehr gut erkennen, wie deutlich der HC im Framebereich von 672 bis 744 gegenüber den anderen Encodern abfällt.

Frame 672 bis 744:
- Cinema Craft Encoder Basic: 0,9416
- HC: 0,9274
- Canopus Procoder Express: 0,9543
- QuEnc: 0,9565

Frame 745 bis 821:
- Cinema Craft Encoder Basic: 0,9537
- HC: 0,9584
- Canopus Procoder Express: 0,9606
- QuEnc: 0,9622

Ich weiß jetzt natürlich nicht, inwieweit diese Aufstellungen überhaupt nützlich für Hank ist. Eventuell weiß er mittlerweile aber auch, woran es liegen könnte, da er mich diesbezüglich bereits kontaktiert hat.

Auch den über einen Frame gemittelten SSIM Werten kann man nur bedingt vertrauen. In meinen Tests mit SSIM habe ich es geschafft, Sequenzen mit Durchschnitts SSIM von 0,95 zu produzieren, die sehr schlecht aussahen, weil einige Ausreißer nach unten dabei sind. Der minimale SSIM ist m.E. ein besserer Indikator (da schlechte Bereiche den Gesamteindruck weiter nach unten reißen als gute nach oben). Leider kann das verfügbare avs Plugin nur den über ein Frame gemittelten Wert ausgeben.

Warum macht der HC bei dir eigentlich nur 1 B-Frame, die anderen aber 2? Anscheinend arbeitet die AutoGOP-Option hier etwas pessimistisch, und verringert bei viel Bewegung die B-Frame-Anzahl, um besser auf die starke Veränderlichkeit zu reagieren, was jedoch dazu führt, dass zu häufig P-Frames mit größeren QF eingebaut werden müssen.

Kopernikus:
Das sind dann die berühmten Bildvergleiche, wo in einem Bild ein Loch bzw. ein kleiner schwarzer Kreis abgebildet ist, rundherum ist das Bild aber völlig identisch.
Das Problem beim minimalen SSIM ist halt auch, wo tritt der auf und wie oft treten solche schlechten Werte überhaupt auf? In Randbereichen stört das weniger als in bildwichtigen Bereichen. Vielleicht so was wie eine Standardabweichung der SSIM-Werte innerhalb eines Frames einführen? Obwohl, wenn ich da an den soeben genannten schwarzen Kreis denke, eher nicht. Vielleicht dann doch eher den kleinsten SSIM-Wert ermitteln.

LigH:
Autogop könnte durchaus der Schlüssel sein. Bei Frame 672 geht es z. B. schon mal los mit 3 x IPPPPPPPPPPPPPP, gefolgt von IPPPPPPPPPPPPPPB und IBPBPBPBPBPBPB.

Ich deaktiviere mal Autogop und lasse den HC mit der Einstellung „15-2“ durchlaufen (bei sonst gleichen Einstellungen).

Also die Variante mit deaktiviertem Autogop und der Einstellung „15-2“ sieht dann doch gefälliger aus. Als Durchschnittswert über alle Frames erhalte ich nun Q = 0,9425. Auch im BitRate Viewer ist die Quantisierungskurve etwas gemäßigter.

HC, „15-2“
[Blockierte Grafik: http://img245.imageshack.us/img245/8736/bitrateviewerhc1520640x0390ho2.jpg]

Hier noch mal die Grafiken, die den Verlauf der SSIM-Werte veranschaulichen. Diesmal allerdings mit der „15-2-Variante“ des HC-Clips.

SSIM-Kurve, Frame 150 bis 407, Wasserszene mit leichtem Schwenk
HC: 0,9214
 [Blockierte Grafik: http://img170.imageshack.us/img170/5272/ssimframehc1520150bis0407pu7.jpg]

SSIM-Kurve, Frame 408 bis 671, langsamer gefühlvoller Schwenk
HC: 0,9444
[Blockierte Grafik: http://img171.imageshack.us/img171/1259/ssimframehc1520408bis0671xk5.jpg]

SSIM-Kurve, Frame 672 bis 821, Nahaufnahme eines Tieres
HC: 0,9496
[Blockierte Grafik: http://img181.imageshack.us/img181/6231/ssimframehc1520672bis0821rz2.jpg]

SSIM-Kurve, Frame 1097 bis 1146, Wasserspringbrunnen
HC: 0,8835
[Blockierte Grafik: http://img169.imageshack.us/img169/9449/ssimframehc1521097bis1146sw0.jpg]

Die Aufsplittung des Framebereichs von 672 bis 821 ergibt diesmal:
Frame 672 bis 744: 0,9422
Frame 745 bis 821: 0,9566

Wenn man sich nun den Framebereich von 672 bis 821 als Video ansieht bzw. die Einzelbilder schnell nacheinander betrachtet, sind auch keine Verblockungen mehr sichtbar. "Auffällig" ist jetzt vielleicht nur noch die Wasserszene (Framebereich von 150 bis 407).

Noch ein kleiner Nachtrag. Ich habe auch noch einen Versuch mit der Einstellung „15-1“ gemacht. Für Q erhalte ich den Wert 0,9418. Da mir aber diese Zahl – aus den oben erwähnten Gründen – noch nicht viel sagt, habe ich mir also wieder die Verlaufskurve angesehen. Und siehe da, das Ergebnis ist wieder schlechter geworden ist. Auch im laufenden Video bzw. beim Betrachten der Einzelbilder sieht man wieder Verblockungen.

Hier noch mal der Framebereich von 672 bis 821 mit dem „15-1-Clip“ des HC-Encoders.

[Blockierte Grafik: http://img168.imageshack.us/img168/3432/ssimframehc1510672bis0821dw4.jpg]

Ich habe mittlerweile von Hank auch einen Hinweis erhalten, dass man der Anzeige des BitRate Viewers bzgl. der Quantisierungskurve wohl nicht so vertrauen kann. Offensichtlich ermittelt der BitRate Viewer die Quantisierungswerte nur unzureichend bzw. falsch.

Ein Bild (Mpeg 2) ist im Prinzip ja nichts anderes als ein mit Makroblöcken ausgefülltes Raster. Makroblöcke werden wiederum zu sog. Slices zusammengefasst (vereinfacht ausgedrückt).

Der BitRate Viewer liest offensichtlich immer nur den ersten Quantisierungswert eines Slices und bildet daraus einen Durchschnitt für den ganzen Frame. Da die Quantisierungswerte, je nach verwendeten Encoder, von Makroblock zu Makroblock aber sehr unterschiedlich sein können, ist die Anzeige alles andere als repräsentativ.

Zitat von Check It Out

Encoder darf man nicht bezüglich Quantisierung vergleichen. Das ist nur innerhalb eines Encoders zu Vergleichszwecken angebracht.

;D