x264 Banding ... Verständnisfrage

    Huhu ... jetzt hats mich erwischt ...

    Ich habe den guten alten Klassiker "Logans Run" (aka "Flucht ins 23te Jahrhundert") auf'm OP-Tisch liegen.

    Source ist (angeblich) BlueRay untouched ... gibts das überhaupt im Matroska-Container?

    Egal ... auf jedenfall ist das übel verrauscht und ich hab das allheilmittel (Neat) drüber gejagt.
    Ergebnis ist grandios ... zumindest solange, bis ich es ins x264 quetsche.

    Encoding Parms sind --crf 18 und --preset slower

    Da spuckts dann in sehr sehr sehr dunklen Bereichen (fasst schwarz) die allseits gehassten Bänder aus.

    Dann hab ich rumprobiert und hab ein "akzeptables" Ergebnis erziehlt mit:

    --qcomp 0.7 --aq-strength 1.2

    ... auch hab ich den gradfun2db() auf den Standardwert (1.2) reduziert.

    Das ist jetzt "viel besser", wenn auch nicht perfekt. Die Gesamt-Dateigröße hat sich zu meinem erstaunen minimal reduziert ... liegt wohl daran, das es mehr Bereiche gibt, die nicht band'en und vom gradfun2db() profitieren.

    Lange Rede, kurzer Sinn ... das ist zwar alles sehr schön, aber erstens möchte ich verstehen, was und warum qcomp und aq-strength das verbessern und zweitens, ob man nicht irgendwie die verbliebenen Banding-Artefakte wegbekommt, ohne den rest des Films zu verschlechtern.

    Hüüllffee :rolleyes_:

    Zitat von TheGenesis

    Source ist (angeblich) BlueRay untouched ... gibts das überhaupt im Matroska-Container?

    Programme wie MakeMKV können Blu-rays auslesen und den Hauptfilm ohne Recodierung aus den MTS-Dateien nach Playliste in MKV verpacken. Hätte dir dein Freund, der dir den Inhalt hat zukommen lassen, sicher sagen können.

    Gradfun3() hab ich schon getestet ... hilft in meinem Falle nicht das banding zu verringern.
    aq-mode hab ich noch nicht getestet, mach ich als nächstes.
    Mehr Bitrate ungern, weil ich eh schon mit crf18 eine große Datei bekomme ... und wie gesagt, bis auf die extrem dunklen Bereiche ist das Video perfekt.

    Ich lass gerade einen Durchlauf mit aq-strength 1.5 machen ... das sieht toll aus, scheint aber die Datei massiv zu vergrößern ... bin aber erst bei 70% und lass den erstmal durchlaufen.

    Glättet der flash3kyuu_deband(dither_algo=2) das aus dem original/script weiter?
    Dann nützt der mir nämlich nix, weil die Ausgabe vom avs tadellos ist ... erst x264 macht die Artefakte rein.

    Wenn das Banding erst durch die AVC-Codierung entsteht, gibt es nur drei Möglichkeiten (die mir gerade einfallen), dem zu begegnen:

    a) Mehr Bitrate (braucht mehr Platz).
    b) Erweiterte Farbtiefe (inkompatibel).
    c) Inloop-Filter-Tuning (ist m.o.w. Glückssache, ob es hilft, kann auch psychovisuell schlecht aussehen).

    Zitat von TheGenesis

    Glättet der flash3kyuu_deband(dither_algo=2) das aus dem original/script weiter?
    Dann nützt der mir nämlich nix, weil die Ausgabe vom avs tadellos ist ... erst x264 macht die Artefakte rein.

    flash3kyuu_deband() dient hauptsächlich demselben Zweck wie gradfun2db() und gradfun3() auch: in der Quelle vorhandenes Banding reparieren. Wenn Deine Quelle kein Banding aufweist, dann nützen sie alle nichts, machen ggf. die Kompression sogar nur noch schwieriger. Man könnte höchstens Rauschfilter und anschließendes Debanding mit Ordered Dither kombinieren, aber das ist kein leichtes Unterfangen.

    Zitat von TheGenesis

    Ich lass gerade einen Durchlauf mit aq-strength 1.5 machen ... das sieht toll aus, scheint aber die Datei massiv zu vergrößern ... bin aber erst bei 70% und lass den erstmal durchlaufen.

    Nutze 2pass, wenn Du schon eine bestimmte Zieldateigröße ins Auge gefasst hast.

    Test mit aq-strength 1.5 ist durch ... Ergebnis ist super, aber +20% Bitrate ... macht auf's ganze Video 1Gb ... ist mir ein bischen zu heftig.

    Inloop hab ich gerade mal kurz mit --deblock 1:1 probiert ... hat nix gebracht ... auf was geh ich da?

    Gleich test ich mal aq-mode 2. Was machen denn die Mods mit mode 3?

    Zitat von sneaker2

    Falls es für Dich in Frage kommt: x264 10 Bit nutzen. (Praktisch inkompatibel zu allem, was kein PC ist.)

    Nein, auch auf Android läuft's prima (Handy, Tablet, Stick...). Da 10-Bit aber nicht unbedingt von den GPUs dekodiert werden können, sollte es schon eine Dual-Core-CPU sein. Getestet: Cortex A9 dual core 2 x 1GHz decodiert 10 Bit SD hervorragend.

    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

    Zitat

    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.

    Das Thema wird im Doom9.org-Thread How To Use Mpeg4 AVC Deblocking Effectively etwas näher beleuchtet. Kurz zusammengefasst: Der Alpha-Wert legt insgesamt die Stärke des Deblockings fest; Beta regelt, wie aggressiv Bildstrukturen als Detail oder Artefakt eingeordnet werden, und passt je nach »Artefaktanteil« die Filterstärke an. x264 verwendet zur Konfiguration die Option --deblock.

    Demnach müsst ich am 2ten Parameter drehen ... eher positive oder eher negative Werte?

    Achso ... aq-mode 2 macht zwar schön kleine Bitraten, aber sieht so aus, als würde ich mode 1 mit aq-strenght 0 verwenden ... bringt nix, hab im mode 2 mal aq-strength auf 2.0 gesetzt und es sah immernoch grottig aus.

    Einmal editiert, zuletzt von TheGenesis (8. September 2013 um 05:05)

    Zitat

    Demnach müsst ich am 2ten Parameter drehen ... eher positive oder eher negative Werte?


    Kommt darauf an, wenn höherer Wert = mehr wird als filterbar (Artefakt) wahrgenommen und potenziell gefiltert.
    Anzumerken sein, das die Deblockwerte keine absoluten Werte sind, sondern nur Modifikatoren sind, welche das grundsätzliche Deblocking nur abschwächen oder verstärken. Es findet trotzdem immer noch eine zusätzliche Modifikation abhängig vom Quantizer des Makroblocks ab, sprich ist der Quantizer hoch wird mehr deblocking durchgeführt.

    Zitat von TheGenesis

    Achso ... aq-mode 2 macht zwar schön kleine Bitraten, aber sieht so aus, als würde ich mode 1 mit aq-strenght 0 verwenden

    Mit Deiner Testmethode kommst Du nicht weiter. Du vergleichst unterschiedliche Einstellungen bei unterschiedlichen Bitraten, wobei der zu erwartende Erkenntnisgewinn entsprechend Null ist. Da Du anscheinend eh schon eine bestimmte Bitrate anpeilst, solltest Du --bitrate (möglichst 2pass) verwenden.

    Eine bestimmte Bitrate peil ich nicht an. Ich kodiere meistens mit CRF18 da kratzen mich ein paar MB nicht ... aber 20% mehr ist schon heftig ... und das "nur" für die paar dunklen Szenen im Film.
    Den rest des Videos will ich ja garnicht verändern ... würde ich mit niedriger/erzwungerner Bitrate ggf. verschlechtern ... "nur" da blöde schwarz geht mir auf den Senkel.

    Ich experimentiere gerade mit --preset veryslow ... lustig ... meine neue Maschine hat scheinbar soviel Reserven, das es zu --slower keinen Performancenachteil gibt :)

    Zitat von TheGenesis

    Eine bestimmte Bitrate peil ich nicht an.

    Anscheinend doch, sonst würdest Du Dich nicht über die zu großen Dateien beschweren. --crf garantiert keine konstante Qualität über unterschiedliche Einstellungen hinweg, deshalb sind Ergebnisse wie "aq-mode 2 macht zwar schön kleine Bitraten" wertlos, weil man die Bitrate über --bitrate bzw. --crf eh quasi beliebig steuern kann. Du hast nur gezeigt, daß weniger Bitrate auch weniger Qualität bedeutet (bzw. strenggenommen nicht mal das).

    Zitat von TheGenesis

    Ich kodiere meistens mit CRF18 da kratzen mich ein paar MB nicht ... aber 20% mehr ist schon heftig ... und das "nur" für die paar dunklen Szenen im Film.

    Den rest des Videos will ich ja garnicht verändern ... würde ich mit niedriger/erzwungerner Bitrate ggf. verschlechtern ... "nur" da blöde schwarz geht mir auf den Senkel.

    Die Einstellungen nur für ein paar Szenen zu steuern wird mit den globalen Einstellungen schwer. Ansonsten bleibt nur manuelle Steuerung über --zones.

    Zitat von TheGenesis

    Ich experimentiere gerade mit --preset veryslow ... lustig ... meine neue Maschine hat scheinbar soviel Reserven, das es zu --slower keinen Performancenachteil gibt :)

    Das halte ich für unwahrscheinlich. Das deutet eher auf einen extremen Flaschenhals in Deinem Skript hin, möglicherweise Multi-Threading-bezogen (CPU-Auslastung im Task Manager beachten).

    Ok ok ... sagen wir mal so, ich möchte "nicht mit aller gewalt Bitrate sparen". Halt einen gesunden Kompromiss finden.

    Hattest recht, veryslow ist bei mir ca. 10% langsamer ... hatte an 2 Schrauben gleichzeitig gedreht.

    10-Bit sieht sehr viel versprechend aus. Ist das abzusehen, das es irgendwann dafür Standalone-Player geben wird? Funktioniert das auf XBbox oder PS2/3?

    Was sagt Youtube zu 10-Bit Files?

    Zitat von TheGenesis

    Ist das abzusehen, das es irgendwann dafür Standalone-Player geben wird?

    Ganz klares: Vielleicht. Bald™.

    Zitat von TheGenesis

    Funktioniert das auf XBbox oder PS2/3?

    Zur Zeit nicht, soweit ich mich erinnere...

    Zitat von TheGenesis

    Was sagt Youtube zu 10-Bit Files?

    YouTube recodiert hochgeladene Videos immer. Wahrscheinlich mit so was wie ffmpeg; wenn du 10-bit-AVC hochlädst, müsste es mittlerweile verarbeitet werden können.

    Zitat von LigH

    YouTube recodiert hochgeladene Videos immer. Wahrscheinlich mit so was wie ffmpeg; wenn du 10-bit-AVC hochlädst, müsste es mittlerweile verarbeitet werden können.

    Scheint inzwischen tatsächlich zu klappen. Als wir das Thema hier das letzte mal hatten, gab es noch böse Artefakte.

    Zitat von TheGenesis

    Ist das abzusehen, das es irgendwann dafür Standalone-Player geben wird?

    Zitat von LigH

    Ganz klares: Vielleicht. Bald™.

    Wirklich durchsetzen konnte es sich im Consumer-Bereich nie. Vielleicht haben wir bei HEVC mehr Glück.

    Zitat von TheGenesis

    Hattest recht, veryslow ist bei mir ca. 10% langsamer ... hatte an 2 Schrauben gleichzeitig gedreht.

    Selbst 10% scheint mir noch zu wenig, aber ok.

    Ok ... das Ergebnis via 10-bit, ohne gradfun() und mit --qcomp 0.7 sowie --aq-strength 1.5 ist DER ABSOLUTE HAMMER!!!

    Sieht 100% aus wie der output vom avs.

    Die Testsequenz ist von der Größe nahezu identisch mit gradfun() und standard-profil.

    Ich lass jetzt mal das ganze Teil rendern und berichte dann was es gegeben hat.

    Daaankeeee für die wertvollen Tipps!!!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden