Block Artefakte bei schlechten Lichtverhältnissen

may24

Hi zusammen,
ich habe einige Video-Kamera .vob's bekommen die deinterlaced und neu (in H264) codiert werden sollen.
Ich habe zunächst mal den QTGMC als Deinterlacer benutzt und --crf 20. Ausgangsmaterial ist MPEG-2 NTSC Interlaced.
Nun habe ich festgestellt das besonders in "Lichtschwachen" Scenen - bei der auch noch die Kamera ordentlich Grain liefert - nach dem Encoden sehr starke Blockartefakte zu sehen sind.

Ich bin leider die Woche nicht zu Hause, sonst hätte ich 'n Schnipsel hoch geladen ... erst ab Sonntag ...

Eine Möglichkeit die Artefaktbildung "etwas einzudämmen" ist natürlich mit der Datenrate hoch zugehen ... So ab CRF 14 wird's erträglich ;D
An --aq-strength zu drehen hat auch nicht wirklich den Erfolg gebracht ...

Vielleicht sollte ich mal die 10-Bit Variante versuchen ... hat da jemand schon mehr Erfahrung gesammelt ?

Wäre es besser für sowas eine andere Matrix zu benutzen ? Und wenn ja welche ?

Für x264 benutze ich folgende Einstellungen:

Code

x264-r2245.exe --crf 20 --level4.1 --b-adapt 2 --bframes 3 --ref 5 --partitions all --direct auto --weightb --me umh --subme 10 --mixed-refs --8x8dct --vbv-bufsize 30000 --vbv-maxrate 38000 --trellis 2 --threads auto --output test.mkv test.avs

Selur

Mal Einstellungen analog zu "-tune grain":

Code

grain (psy tuning):
                                    --aq-strength 0.5 --no-dct-decimate
                                    --deadzone-inter 6 --deadzone-intra 6
                                    --deblock -2:-2 --ipratio 1.1 
                                    --pbratio 1.1 --psy-rd <unset>:0.25
                                    --qcomp 0.8

versucht?

Zitat

Ich habe zunächst mal den QTGMC als Deinterlacer benutzt und --crf 20. Ausgangsmaterial ist MPEG-2 NTSC Interlaced.

Welche Einstellungen? (hoffe mal stark, dass das Material wirklich interlaced und nicht telecined ist, sonst ist QTGMC i.d.R. das falsche Tool)

Zitat

Vielleicht sollte ich mal die 10-Bit Variante versuchen ... hat da jemand schon mehr Erfahrung gesammelt ?

Wird zumindest indirekt helfen, da es die Effizienz der Kodierung erhöht und durch die erhöhte Genauigkeit auch leichte Helligkeitsübergänge ohne Banding encoded werden.

Zitat

Wäre es besser für sowas eine andere Matrix zu benutzen ? Und wenn ja welche ?

Wenn Du nicht weißt wie die Matrizen in H.264 funktionieren und wie eine Matrix für Deine Bedürfnisse aussehen muss lass besser die Finger davon. Selbst wenn man genau weiß was man tut ist es i.d.R. einfacher über die psychovisuellen Einstellungen gute Ergebnisse zu erreichen, sprich man macht mit Matrizen eher etwas kaputt als das man etwas rettet.

Zitat

Ich bin leider die Woche nicht zu Hause, sonst hätte ich 'n Schnipsel hoch geladen ... erst ab Sonntag ...

Am besten postest Du dann auch direkt Dein AvisynthSkript.

Cu Selur

LigH

Bei MPEG2 und MPEG4-(A)SP waren andere Matrizen noch halbwegs brauchbar, weil man die DCT noch gut verstand.

Lass das bei MPEG4-AVC und x264 bloß bleiben! Es ist zwar möglich, aber funktioniert doch wesentlich anders mit der Integer-Transformation in H.264; auch ist x264 auf die Standard-Matrix optimiert.
__

So, noch mal zurück zu den VOBs ... nach deinen Aussagen wurden die von einer DVD-Handycam erstellt, also Hardware-Echtzeit-Encoder, ziemlich konstante Bitrate und kaum psychovisuelle Optimierungen.

Gibt es schon sichtbare Blöcke im Original-Video? Vermutlich kannst du da noch etwas mit dem Deblocking erreichen. Schade nur, dass DGMPGDec immer noch nur den alten Deblocker (von Nic?) enthält, der zwar abhängig von der Quantisierung arbeitet, aber technisch nicht ganz ausgereift ist; der Deblock-Filter – von Manao oder Fizick zu bekommen – arbeitet mit dem H.264-Inloop-Filter, ist also technisch fortgeschritten, aber man muss eine Quantisierung manuell wählen. Donald Graft hält es leider nicht für hinreichend wichtig, mal beide zu kombinieren...

Dann würde ich außerdem noch das Tuning "Film" vorschlagen, wenn du recht deutlichen Gries im Bild hast. Ob der "Entrauscher" (oder besser: Rausch-Modellierer) in x264 was bei deinem Material nützt, müsstest du für dich testen; der eine oder andere hier war "begeistert" davon... oder du suchst dir einen guten Gries-Filter in AviSynth, aber das kann schwierig werden. Zuerst fällt einem da vielleicht DeGrain ein.

P.S.: Tuning "film" ist bereits für leichten Gries geeignet, Tuning "grain" dafür schon recht extrem (für solche absichtlich vergriesten Filme wie "300" vielleicht).

may24

Selur: Doch es ist Interlaced ... Wieso sollte QTGMC deas falsche Tool zum deinterlacen sein ? Oder meinst du das das Motion-compensation schon zu viel kaputt macht ? Wenn ja, was wäre denn die "bessere Wahl" ?
Na ja das avs ist recht simpel:

Code

Import("\c:\programme\video Filter\QTGMC-3.32\qtgmc.avsi")


Mpeg2Source("demux_vob.d2v")
QTGMC(Preset="Slower", EdiThreads=2)
Spline36Resize(848,480)
FadeIO(30)


return(last)

LigH

QTGMC ist hervorragend geeignet zum Deinterlacen.

Aber es ist überhaupt nicht geeignet für das "Inverse Telecine" (Telecine ist eine Technik, bei der 24 fps Film auf knapp 30 fps NTSC umgerechnet wird, indem regelmäßig ein paar Halbbilder wiederholt werden).

Allerdings wage ich zu behaupten, dass eine Videokamera für Heimanwender kein Telecine aufzeichnet. Es wird wahrscheinlich schon echtes Interlacing sein.

Selur

Das mit QTGMC hat LigH ja erklärt. QTGMC ist für interlactes Material super, aber für telecined Material eben nicht. (nebenbei sei erwähnt, dass ich dazu raten würde Avisynth MT zu verwenden, damit QTGMC nicht so langsam ist)

Zitat

Allerdings wage ich zu behaupten, dass eine Videokamera für Heimanwender kein Telecine aufzeichnet. Es wird wahrscheinlich schon echtes Interlacing sein.

Kann sein, muss ehrlicherweise sagen, dass ich noch nie Material von einer "Videokamera für Heimanwender" hatte die direkt vobs auswirft.

LigH

Es gibt welche, die direkt auf 8-cm-DVDs brennen. Beim Finalisieren werden UDF- und ISO-Dateisystem aktualisiert bzw. erzeugt.

Das soll aber sicher keine Kaufempfehlung sein...

may24

Also mit welcher Kamera aufgenommen wurde kann ich nicht sagen. Ich habe eine home-made-DVD mit entsprechendem Material erhalten. Soweit ich das sagen kann ist's "echtes Interlaced Video" und kein telecined ...

... so wie's aussieht brauchen wir hier echt einen Schnipsel zum probieren ... zu blöd das ich keinen mitgenommen habe ... Aber kommt noch

may24

So, bin endlich mal dazu gekommen einen Schnipsel hochzuladen. Link

Nur so'ne Idee. Könnte man mit den Dither-Tools die Teile "dithern" die sich sonst als Block-Artefakte zeigen würden ? Wenn man das Ganze dann noch in 10-bit Farbtiefe komprimiert, sollte das ein anständiges Ergebnis liefern ohne das die Bitrate über den Wolken liegt ...

Didée

Nur für Spass, mal ganz schnell.

[Blockierte Grafik: http://thumbnails107.imagebam.com/24429/58ddb3244282414.jpg] [Blockierte Grafik: http://thumbnails103.imagebam.com/24429/9f0f12244282406.jpg] [Blockierte Grafik: http://thumbnails103.imagebam.com/24429/c10ded244282397.jpg]

Probieren. Hey, so übel ist das gar nicht.

may24

Hi zusammen,

also ich komme hier nicht weiter. Ich hab' aufgegeben den "dither" zu verstehen bzw. vernünftig zum laufen zu bringen. Außerdem geht's hier ja auch nicht (wirklich) um debanding sonder um die Idee: Wenn ich resize und Zwischenwerte entstehen diese im 10 bit (resp. 16 bit) Format zu belassen und das Ganze dan mit x264-10bit zu encoden, einfach um weniger Artefakte - vorallem in dunklen Bereichen - zu bekommen.
Also den dither ad acta gelegt und ResampleHQ versucht. Na ja, ob der wirklich 16bit Tiefe pro Kanal produziert läßt schlecht nachweisen ...

Jedenfalls ist das "Endergebnis" nicht viel besser geworden. Vielleicht liegt's auch am Motion-compensation des QTGMC ...
Oder ganz was anderem ? Um das Blocking mal zu bekämpfen habe ich den Deblock_QED vorher noch reingeschoben.

Hier mein .avs:

Code

Import("C:\Program Files (x86)\Video Tools\QTGMC-3.32\QTGMC-3.32.avs")Import("C:\Program Files (x86)\Video Tools\Deblock_QED.avs")LoadPlugin("C:\Program Files (x86)\Video Tools\AddGrainC___(1.5_-_2010-05-07)\AddGrainC.dll")LoadPlugin("C:\Program Files (x86)\Video Tools\masktools-v2.0a48\mt_masktools-26.dll")LoadPlugin("C:\Program Files (x86)\Video Tools\RemoveGrain___(1.0b_-_2005-07-07)\RemoveGrainSSE3.dll")LoadPlugin("C:\Program Files (x86)\Video Tools\ResampleHQ-v8\ResampleHQ\resamplehq-x86.dll")Mpeg2Source("test.demuxed.d2v")QTGMC(Preset="Slower")Deblock_QED(40)ResampleHQ(848,480,dither=true,chroma_kernel="Spline36")return(last)

und:

Code

"C:\Program Files\x264\x264-10bit-r2273" --crf 18 --b-adapt 2 --bframes 3 --ref 5 --partitions all --direct auto --me umh --subme 10 --trellis 2 --threads auto --output test-10b-18.mkv test.avs

Als Vergleich das Ganze nochmal mit der 8-Bit Variante. Doch außer der unterschiedlichen Dateigröße kann ich da keinen Unterschied hinsichtlich der Quali erkennen. Es kommt immer zu sehr häßlichen geflacker und Blockartefakten.

Ich bin mir nicht 100% sicher wie Didée's Deblock_QED hinsichtlich des Deblockings arbeitet. Oder anders ausgedrückt: wie werden denn die Kanten der Blöcke geglättet ?
Könnte man einen Deblocker bauen (scripten ?) der die Kanten Dithered ? Und vielleicht auf größere Bereiche als 3x3 Blöcke anwendet. Das ganze kann/sollte vielleicht im 10 Bit (16Bit) Farbenraum liegen ... ?

Goldwingfahrer

Zitat

RemoveGrainSSE3

seit wann ist denn die Variante "3" wieder freigegeben also bugfrei ?

Hier heissts immer nur die SEE2 einsetzen.

sneaker2

Zitat von may24

Hi zusammen,

also ich komme hier nicht weiter. Ich hab' aufgegeben den "dither" zu verstehen bzw. vernünftig zum laufen zu bringen. Außerdem geht's hier ja auch nicht (wirklich) um debanding sonder um die Idee: Wenn ich resize und Zwischenwerte entstehen diese im 10 bit (resp. 16 bit) Format zu belassen und das Ganze dan mit x264-10bit zu encoden, einfach um weniger Artefakte - vorallem in dunklen Bereichen - zu bekommen.

Wie soll das mit ResampleHQ gehen, wenn der nur 8 bit als Ausgabe hat? Und die "dither" tools für AviSynth umfassen mehr, als nur Debanding.

Davon abgesehen: mir ist nicht ganz klar inwieweit hier ein anderer Resizer überhaupt etwas gegen Blöcke helfen soll?

LigH

Solange du bei YV12 bleibst, bleibst du auch bei 8 bit pro Kanal. Und selbst in feineren Chrominanzauflösungen für AviSynth 2.60 werden nur 8 bit pro Kanal verwendet.

Ich weiß nicht, ob x264 intern mit höherer Auflösung herunterrechnen würde, wenn du in AviSynth 2.60 mit YV24 (YUV 4:4:4 mit je 8 bit) arbeitest, und das Chroma-Subsampling zurück zu YUV 4:2:0 innerhalb von x264 stattfindet.

Aber wenn das Blocking und Banding so deutlich ist, dann ist das auch mehr als nur das Bit 1 von 8...

Soweit mir bekannt ist, arbeitet Deblock_QED mit etwa dem gleichen Inloop-Deblocking wie das H.264-Verfahren.

sneaker2

Zitat von LigH

Solange du bei YV12 bleibst, bleibst du auch bei 8 bit pro Kanal. Und selbst in feineren Chrominanzauflösungen für AviSynth 2.60 werden nur 8 bit pro Kanal verwendet.

Mit den Dither tools bekommt man mehr als 8 bit pro Kanal auch unter AviSynth mit 4:2:0. Sind dann halt solche Top-Bottom- oder Interleaved-Hacks, die x264cli dann wieder zurück auf 10-bit rechnen kann.

Zitat von LigH

Ich weiß nicht, ob x264 intern mit höherer Auflösung herunterrechnen würde, wenn du in AviSynth 2.60 mit YV24 (YUV 4:4:4 mit je 8 bit) arbeitest, und das Chroma-Subsampling zurück zu YUV 4:2:0 innerhalb von x264 stattfindet.

Nein, tut x264cli nicht. Das ist wirklich eine simple Kette, bei der zuerst das Bild ins gewünschte Format gebracht wird und erst danach libx264 damit gefüttert wird. Hätte also keine Vorteile gegenüber dem Resizen mit AviSynth.

Zitat von LigH

Aber wenn das Blocking und Banding so deutlich ist, dann ist das auch mehr als nur das Bit 1 von 8...

Ich glaube er meint eher 10 bit x264. Das hängt ja nicht direkt mit dem Chroma-Subsampling zusammen.

Zitat von LigH

Soweit mir bekannt ist, arbeitet Deblock_QED mit etwa dem gleichen Inloop-Deblocking wie das H.264-Verfahren.

Ich glaube der Begriff "Inloop-Deblocking" ergibt innerhalb von AviSynth bzw. außerhalb eines Encoder-/Decoder-Kontextes keinen Sinn, auch wenn das eigentliche Deblocking ähnlich ist.

LigH

Zitat von sneaker2

Mit den Dither tools bekommt man mehr als 8 bit pro Kanal auch unter AviSynth mit 4:2:0. Sind dann halt solche Top-Bottom- oder Interleaved-Hacks, die x264cli dann wieder zurück auf 10-bit rechnen kann.

Versteh ich nicht so recht. Im RAM werden doch nur immer je ein Byte = 8 bit pro Element in den Komponenten Y, U und V verwendet. Das einzige, was Dithering tut, ist gezielte Abweichungen zu erzeugen, eine Art "planmäßiges Rauschen", dessen Mittelwerte dann einen sanfteren Übergang erscheinen lassen.

Zitat von sneaker2

Ich glaube er meint eher 10 bit x264. Das hängt ja nicht direkt mit dem Chroma-Subsampling zusammen.

Und ich meine, dass so offensichtliche Artefakte vermutlich mehr als 1/256 des Helligkeitsumfanges darstellen (TV-Scale mal ignoriert). Da ist es müßig, "weniger als 1/256" dithern zu wollen.

Beim Chroma-Subsampling dachte ich, dass AviSynth vielleicht YUV 4:4:4 (YV24) an x264 schickt (meinetwegen gedithert), und x264 rechnet dann aus je 2x2 Chroma-Werten in 8 bit einen Mittelwert in 10 bit für YUV 4:2:0 herunter. Aber der Helligkeit würde das auch nicht helfen, Y hat ja immer volle Auflösung...

Alles in allem verstehe ich also bis heute nicht, wie denn die 10 bit zustande kommen sollen. Vermutlich ergeben die sich erst nach der H.264-Integer-Transformation, haben also gar nichts mit den eigentlichen YUV-Samples zu tun, sondern mit ihrer Frequenzdarstellung in den (Makro-) Blöcken und -partitionen.

Zitat von sneaker2

Ich glaube der Begriff "Inloop-Deblocking" ergibt innerhalb von AviSynth bzw. außerhalb eines Encoder-/Decoder-Kontextes keinen Sinn, auch wenn das eigentliche Deblocking ähnlich ist.

Mag wohl sein, sicher gäbe es da eigentlich enge Zusammenhänge mit der transformierten Makroblock-Parameterdarstellung; aber nach meinen Erinnerungen hatte das manao für die MaskTools nach dem Vorbild entwickelt, und Fizick hat es als Deblock() einzeln verfügbar gemacht.

Jedenfalls müsste es deutlich besser sein als Nic's Deblocking in MPEG2Dec. Deshalb wollten wir ja mal DG dazu bewegen, das dort einzubauen, weil dann auch die Quantisierung aus der Quelle bekannt wäre. Nur scheint Deblock() auf die Quantisierungsschritte bei H.264/AVC entwickelt zu sein, und die bei H.262/MPEG2 sind dann doch deutlich anders im Verlauf.

sneaker2

Zitat von LigH

Versteh ich nicht so recht. Im RAM werden doch nur immer je ein Byte = 8 bit pro Element in den Komponenten Y, U und V verwendet. Das einzige, was Dithering tut, ist gezielte Abweichungen zu erzeugen, eine Art "planmäßiges Rauschen", dessen Mittelwerte dann einen sanfteren Übergang erscheinen lassen.

Jein. Mit "dither" meinte ich den Eigennamen des entsprechenden AviSynth-Plugins. Dithering selbst verwendet man ja beim Verringern der Präzision, also z.B. von 10 bit auf 8 bit. Die "dither"-Tools können Resizen mit z.B. 16-Bit-Genauigkeit und das Ergebnis über diese Hacks direkt an x264 ausgeben, welches es dann auf 10 bit runterrechnet. Durch diesen Hack vermeidet man hier also die unnötige Zwischenstufe auf 8 bit völlig. x264 10bit bedeutet ja neben der erhöhten Präzision für die interne Berechnung auch, daß bei der Ein- und Ausgabe jedes Y-, U- und V-Element 10 bit hat. Entscheidend für die bessere Kompression ist eigentlich nur die höhere Präzision der internen Berechnungen, aber nichtsdestotrotz erhöht sich auch die Präzision der Ein- und Ausgabe.

Zitat von LigH

Und ich meine, dass so offensichtliche Artefakte vermutlich mehr als 1/256 des Helligkeitsumfanges darstellen (TV-Scale mal ignoriert). Da ist es müßig, "weniger als 1/256" dithern zu wollen.

Was es hier bringen soll, ist mir auch nicht klar.

Zitat von LigH

Beim Chroma-Subsampling dachte ich, dass AviSynth vielleicht YUV 4:4:4 (YV24) an x264 schickt (meinetwegen gedithert), und x264 rechnet dann aus je 2x2 Chroma-Werten in 8 bit einen Mittelwert in 10 bit für YUV 4:2:0 herunter. Aber der Helligkeit würde das auch nicht helfen, Y hat ja immer volle Auflösung...

Nein, x264cli zieht wirklich keine Vorteile daraus, weshalb man ruhig bereits in AviSynth aufs Zielformat gehen kann.

Zitat von LigH

Mag wohl sein, sicher gäbe es da eigentlich enge Zusammenhänge mit der transformierten Makroblock-Parameterdarstellung; aber nach meinen Erinnerungen hatte das manao für die MaskTools nach dem Vorbild entwickelt, und Fizick hat es als Deblock() einzeln verfügbar gemacht.

Jedenfalls müsste es deutlich besser sein als Nic's Deblocking in MPEG2Dec. Deshalb wollten wir ja mal DG dazu bewegen, das dort einzubauen, weil dann auch die Quantisierung aus der Quelle bekannt wäre. Nur scheint Deblock() auf die Quantisierungsschritte bei H.264/AVC entwickelt zu sein, und die bei H.262/MPEG2 sind dann doch deutlich anders im Verlauf.

Ich meinte halt, weil ein AviSynth-Plugin (also auch Deblocker) im Grunde immer nur die Rohdaten des vorherigen Plugins bekommt. "Inloop" bedeutet ja, daß ein Bild dekodiert wird, dann deblockt und dann das deblockte Bild als Referenz für das darauffolgende genommen wird. Innerhalb von AviSynth existieren aber ein Dekoding bzw. P- und B-Frames in dem Sinne gar nicht, sondern es sind effektiv alles verlustfreie I-Frames.

LigH

Meinst du diese Dither-Tools? Da kann ich erst mal keine "geheime Kommunikation zwischen dem Plugin und x264" erkennen, welche die Videoausgabe von AviSynth ergänzt. Allerdings lese ich was von "Bayer matrix".

Libcaca study: the science behind colour ASCII art — 2. Halftoning (2.3 Ordered dither)

Ich glaube, da müssen wir alle noch mal genauer nachlesen, was die AviSynth-Wiki unter dem folgenden Thema zusammenfasst:

High bit-depth Support with Avisynth

Die Probleme von may24 liegen allerdings wahrscheinlich noch eine Größenordnung über solchen Spitzfindigkeiten.

Didée

Also, das mit DeblockQED (oder irgend'nem anderen Deblocker) ist Quark, das bringt so gut wie garnichts. Nochmal zurück zu Post#1.

Zitat von may24

besonders in "Lichtschwachen" Scenen - bei der auch noch die Kamera ordentlich Grain liefert - nach dem Encoden sehr starke Blockartefakte zu sehen sind.

Wenn die Blockbildung im Originalmaterial nicht drin ist, sondern erst nach dem neuerlichen Encoden .... was soll es dann bringen, vor dem Encoder einen Deblocker einzusetzen?

Die Commandline sieht im Prinzip nicht übel aus, das was drin steht ist okay ... versuch' mal, die folgenden Parameter zusätzlich einzubinden:

Code

--crf 16 --preset slow --tune film --rc-lookahead 20 --subme 10 --trellis 2 --deadzone 6,6 --no-fast-pskip 
--no-dct-decimate --qcomp 0.50 --psy-rd 1.05:0.15 --aq-mode 1 --aq-strength 1.25

Ohne Gewähr natürlich, aber ... "Versuch macht kluch".

sneaker2

Zitat von LigH

Meinst du diese Dither-Tools?

Ja.

Zitat von LigH

Da kann ich erst mal keine "geheime Kommunikation zwischen dem Plugin und x264" erkennen, welche die Videoausgabe von AviSynth ergänzt. Allerdings lese ich was von "Bayer matrix".

Die Kommunikation ist nicht geheim, Dein Link zur AviSynth-Seite erklärt ja wie es geht (weiter unten unter "Exporting High Bit-depth Video"). Mit VapourSynth kann man sogar direkt mit y4m >8 bit pipen.

So sieht der Hack in z.B. VirtualDub aus:
[Blockierte Grafik: http://www.abload.de/img/high_bitdepth_stackedolzeo.jpg]

Oben die ersten 8 Bit und unten die letzten 8 Bit. Für x264 nimmt man aber die Interleaved-Variante, d.h. eine Zeile die ersten 8 Bit, dann die nächsten 8 Bit etc. Das roh über eine Pipe an x264cli gefüttert und er kann es wieder zu 16 Bit zusammensetzen. Für AviSynth ist es weiter 8 bit. Vielleicht hätte ich lieber "Workaround" anstatt "Hack" schreiben sollen - das trifft es wohl eher.

Zitat von LigH

Die Probleme von may24 liegen allerdings wahrscheinlich noch eine Größenordnung über solchen Spitzfindigkeiten.

Ja, das vermute ich auch.

Jetzt mitmachen!