4K UHD Denoising mit FFT3DGPU,FFT3DFilter,neo_fft3d (Performance,Bugs,VapourSynth-Umsetzung,...)

  • Nebenbei: Mal überlegt anstatt AviSynth&Co zu nutzen mal eher die Noisereduction in x264&x265 zu verwenden?

    Zumindest wenn es vor allem um erhöhte Komprimierbarkeit geht sollte die NoiseReduction nicht schlecht sein.

    Ja, kenn ich die Funktion, und es wäre aufgrund der Anmerkung von LigH bezüglich der Erhöhung der Komprimierbarkeit ohne wirkliches Reduzieren des Rauschens eine Idee, das künftig bei Videos mit eher wenig Artefakten zusätzlich mit moderaten Werten zuzuschalten und bei fft3dgpu Sigma etwas abzusenken.

    Oder aus Performancegründen (bei 4K, 10Bit & Co) wäre es bei solchen Videos wohl auch einen Versuch Wert nur Y mit fft3dgpu zu filtern, und dann noch den x264 denoiser mit 1000-2500 zuzuschalten.

    Allerdings geht es mir nun auch nicht ausschließlich um die Komprimierbarkeit, es dürfen auch gerne hässliche Effekte im Original reduziert werden.

    Die Möglichkeit z.B. mit Hybrid "Only Dark" Bereiche an fft3dgpu zu geben, oder in fft3dgpu nur Y oder UV oder bestimmte Frequenzbereiche stärker zu filtern, ist schon nicht schlecht. So kann man sich auf Bereiche konzentrieren, die besonders durch Artefakte auffallen, da mit hohen Sigma Werten filtern und den Rest schonend behandeln.

  • 4K content mit fft3dgpu im mode 2 nur Y zu filtern scheint tatsächlich eine Alternative zu sein (bei meiner mittlerweile etwas schwachbrüstigen GPU). Den üblichen, selbst nervig auffälligen noise bekommt man trotzdem gut reduziert. Wenn man dann noch den Codec-internen noise filter mit z.B. nur 1000 mitlaufen lässt, passt auch die Komprimierbarkeit. Chroma noise reduction bei 4K werde ich mir (außer für Testzwecke) denke ich künftig schenken, wenn's nicht gerade explizit in der Hinsicht stark verhunztes Material mit irgendwelchem stark auffälligem Farbflimmern ist.

    Selur:

    Und hast du mal überlegt bei fft3dgpu die Konvertierung ins Zielfarbformat per default for den Filteraufruf zu setzen?

    Kann ja heute Abend mal noch testen wie's bei YUV422 aussieht. RGB content hab ich leider keinen.

    Ich finde potentiell bis zu 82% mehr Speed sind ein Effizienzgewinn, der nicht ignoriert werden sollte, wenn da am Ende praktisch identischer content rauskommt und gerade im UV Bereich der SSIM fast durchgängig bei 0.999x liegt. Bei PSNR + MSE sieht's ähnlich aus, selbst einzelne Ausschläge bewegen sich in einem bei 10 Bit content völlig unbedenklichen Bereich. Würde fast wetten, dass crf 16 statt crf 19 bei x264 die Unterschied noch weiter marginalisiert (und das ist es ja, was ein Adlerauge vermutlich verwenden würde).

    Für den einen User, der's unbedingt braucht heutzutage so viel zusätzliche Rechenzeit zu verplempern um einen nicht sichtbaren Unterschied im Output zu haben, könnte man diese Avisynth TuneUp Einstellung ja umkehrbar machen. aber vermutlich existiert dieser User ohnehin nicht, denn der würde vermutlich gar keinen noise filter verwenden :)

    Werde bei Gelegenheit auch mal checken wie's sich mit fft3dfilter + neo_fft3d verhält und ob das eher was mit den fft Algorithmen oder mit fft3dgpu im speziellen zu tun hat.

    Einmal editiert, zuletzt von mogobime (25. Mai 2022 um 23:39)

  • Zitat

    Und hast du mal überlegt bei fft3dgpu die Konvertierung ins Zielfarbformat per default for den Filteraufruf zu setzen?

    Nope. Bin kein Freund von erzwungenen Konvertierungen.

    Aktuell macht Hybrid das so:

    1. Jeder Filter hat eine Menge an Farbräumen zu denen er kompatible ist.

    2. Konvertiert wird nur wenn der aktuelle Farbraum nicht in dieser Menge ist.

    Dadurch sollen so lange wie möglich Informationen aus der Quelle erhalten bleiben.

    Was Du machen kannst ist einfach wo immer Du willst in eine entsprechende 'Custom'-Sektion einen Convert-Aufruf packen und Hybrid mit:

    Code
    # colorformat <RGB/RGB24/RGB32/YUY2/Y8/YV411/YV12/YV16/YV24>

    wissen lassen, dass in der Custom-Sektion sich das Farbformat geändert hat.

    Cu Selur

  • cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv - 4K, 10 bit, YUV422 mit FFT3DGPU

    FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-prefetch(1,X+1)-ConvertToYUV420() [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

    Bestwert: 7.84 fps


    ConvertToYUV420-prefetch(X)-FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-PreFetch(1,X+1) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

    Bestwert: 8.92 fps

    -> X264 13,8% schneller mit ConvertToYUV420() for Filteraufruf.


    6 FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-prefetch(1,X+1)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter64):

    6 ConvertToYUV420-prefetch(X)-FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-PreFetch(1,X+1) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter64):

    -> Avsmeter64 18,4% schneller mit ConvertToYUV420 vor Filteraufruf.


    Qualitätsmetriken - direkter Vergleich der beiden output clips miteinander:

    Code
    SSIM Y:0.998380 (27.904786) U:0.998879 (29.502780) V:0.998719 (28.923470) All:0.998520 (28.296061)
    PSNR y:56.946899 u:58.587585 v:58.052360 average:57.355967 min:51.789978 max:inf
    PSNR y:56.907363 u:58.585376 v:58.050940 average:57.326495 min:51.783484 max:inf
    VMAF score: 99.142670

    -> Auch hier für Normalnutzer vernachlässigbare marginale Unterschiede zwischen den beiden output videos.

  • Yes, if you feed FFT3DGPU with a color space which holds less data to filter it is faster. :)

    Antworte mal auf deutsch, sonst brauch ich hier noch länger um was "zu Papier" zu bringen ;)

    Am deutlichsten ist's wohl beim YUV444 Farbraum, aber auch hier bei YUV422.

    Am Ende der x264 logfiles sind diesmal jeweils per ffmpeg die Unterschiede im SSIM/PSNR zwischen dem unveränderten input video und dem output Video ermittelt (keine Werte von x264, welches den Unterschied zwischen gefiltertem input und dem output video wiedergeben würde).

    Man muss bedenken, dass ich hier mit CRF 10 gearbeitet habe, d.h. schon das sind Werte, die wohl die meisten als "nahe losless" bezeichnen würden.

    Die Werte, wenn das akuratere setting mit ConvertToYUV420() erst am Ende verwendet wurde, Vergleich input mit output:

    Code
    SSIM Y:0.846540 (8.140056) U:0.980199 (17.033228) V:0.978513 (16.678183) All:0.890812 (9.618259) 
    PSNR y:17.832339 u:33.634492 v:32.988516 average:19.532021 min:7.664472 max:64.968725

    Die Werte beim Vergleich output FFT3DGPU-ConvertToYUV420 mit output ConvertToYUV420()-FFT3DGPU:

    Code
    SSIM Y:0.998395 (27.944505) U:0.998879 (29.505425) V:0.998719 (28.925446) All:0.998530 (28.325625)
    PSNR y:56.946899 u:58.587585 v:58.052360 average:57.355967 min:51.789978 max:inf

    -> PSNR + SSIM sind bei logarithmischer Skala im UV Bereich trotz der vorgezogenen Farbraumkonvertierung fast doppelt so hoch wie zwischen Original und einem "regulär" mit CRF 10 enkodierten Video, nur um mal einen Maßstab zu haben um was für mickrige Unterschiede es da geht!

    Einmal editiert, zuletzt von mogobime (27. Mai 2022 um 21:27)

  • Bei neo_fft3d waren die Geschwindigkeitsunterschiede bei exakt gleichem Setup sogar noch deutlicher.

    cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv - 4K, 10 bit, YUV422 mit neo_fft3d

    neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

    Bestwert 5.17 fps

    ConvertToYUV420-prefetch(X)-neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

    Bestwert 6.27 fps

    -> X264 21,3% schneller mit ConvertToYUV420() for Filteraufruf.

    6 neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AVSMeter):

    6 ConvertToYUV420-prefetch(X)-neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter):

    -> Avsmeter64 35,8% schneller mit ConvertToYUV420() vor Filteraufruf!

    Qualitätsmetriken - Beide output clips direkt miteinander verglichen:

    Code
    PSNR y:56.610453 u:59.156317 v:58.542447 average:57.234147 min:51.751340 max:inf
    SSIM Y:0.998271 (27.620884) U:0.998980 (29.914837) V:0.998813 (29.254114) All:0.998479 (28.179166)
    VMAF score: 99.146489

    Btw - obwohl FFT3DGPU bei 4K 10 Bit YUV422 content bereits meiner RX 560 Budget GPU mit 4 GB die Grenzen aufzeigt und sie mit knapp 80% auslastet, ist es immer noch 25,1% schneller. Stromverbrauch geht dabei, wie schonmal erwähnt um max 10% oder 30W hoch, in dem Fall ist er sogar niedriger, da die CPU sich die meiste Zeit langweilt :)

    Und neofft3d lastet hier die CPU bereits mit rund 90% aus, da ist also für nen codec nicht viel Rechenkapazität übrig...

  • cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv - 4K, 10 bit, YUV422 mit FFT3DFilter

    FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

    Bestwert 3.68 fps

    ConvertToYUV420-prefetch(X)-FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

    Bestwert 4.61 fps

    -> X264 25,3% schneller mit ConvertToYUV420() for Filteraufruf.

    6 FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AVSMeter64):

    6 ConvertToYUV420-prefetch(X)-FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter64):

    -> Avsmeter64 25,8% schneller mit ConvertToYUV420() vor Filteraufruf!

    Qualitätsmetriken - direkter Vergleich der beiden output clips miteinander:

    Code
    PSNR y:56.688991 u:59.165395 v:58.551171 average:57.296540 min:51.909493 max:inf
    SSIM Y:0.998295 (27.682848) U:0.998983 (29.925964) V:0.998815 (29.264141) All:0.998496 (28.228635)
    VMAF score: 99.151086
  • Fazit für YUV422

    Gleich vorneweg nochmal: Alle Messungen wurden, wie zuvor auch, per Skript mind. 2-3x durchgeführt und nur das beste Messergebis gespeichert um Zufallsschwankungen durch startende Hintergrundprozesse etc. möglichst auszuschließen bzw. zu reduzieren.

    Hier sieht es doch so aus, als ob nicht nur das Multithreading bei neo_fft3d verbessert wurde.

    CPU Auslastung war bei neo zwar 5-8% höher, aber neo_fft3d war bei bei

    X264 bis zu 40,5% (regular) / 36% (early yuv420 conversion) schneller als das normale FFT3DFilter und bei AVSMeter bis zu 31,2% (regular) / 41,8% (early yuv420 conversion).

    FFT3DGPU setzt sich hier logischerweise noch weiter von FFT3DFilter ab:

    X264 213% (regular) / 193% (early yuv420 conversion) und AVSMeter 88,2% (regular) / 77,3% (early yuv420 conversion).


    Bei X264 muss man bedenken, dass bei FFT3DGPU und x264 preset superfast die CPU zu nur etwa 15% ausgelastet war.

    Bei einem im realen Einsatz verwendeten preset fast oder medium müssten die Unterschiede noch gravierender sein, da dürften sich neo_fft3d + fft3dfilter nochmal knapp halbieren, während FFT3DGPU nur 10-25% langsamer werden sollte. Also selbst mit dieser älteren Budget GPU vermutlich real world Zugewinne um bis zum Dreifachen durch FFT3DGPU, da über 90% der Rechenkapazität fürs encoding freibleiben.

    Für YUV422 input bei FFT3DFilter + neo_fft3d gilt: Sie kommen damit noch schlechter klar als FFT3DGPU, und der Geschwindigkeitsvorteil durch "early yuv420 conversion" bringt (im Fall von neo_fft3d) sogar fast doppelt so viel Geschwindigkeitszuwachs wie bei FFT3DGPU!

    Hier sollte man erst Recht darüber nachdenken, den ConverToYUV420 call vorzuziehen, wenn man das chroma subsampling aufs übliche YUV420 ändert.

  • Nachtrag zum YUV422 Vergleich:

    Hab bei den 3 Filtern noch SSIM und vor allem die Netflix Qualitätsmetrik VMAF ergänzt, die KI basiert arbeitet um die menschliche Wahrnehmung möglichst gut abzubilden.

    Um es kurz zu machen: Die files bei denen die Farbraumkonvertierung vor dem Filteraufruf durchgeführt wurden Unterscheiden sich auch hier praktisch nicht. VMAF score liegt jedesmal über 99 (100 ist max).

    So hohe Werte werden z.B. in der Praxis bei einem Vergleich Quelle -> encodetes file praktisch nie erreicht. Auch der SSIM liegt immer bei 0.99x.

    Zip-Files hab ich durch neue mit den Logfiles und Werten für jedes einzelne Frame ersetzt

  • Deswegen kann man entsprechenden 444/422 Input auch auf 420 downsampeln, und das am Besten in einem AviSynth Skript gleich als allerestes, im Falle von 444 spart das immens Rechenleistung...

    Jedenfalls ist es (außer vielleicht in irgendwelchen ganz speziellen Fällen, wo man irgendwas einzeln mit dem Chroma machen will) ziemlich unsinnig das erst am Ende des Skripts zu machen und desewegen bei 444 schlimmstenfalls die doppelte Rechenzeit in Anspruch zu nehmen.

    OT: Putin hasst das...

  • Kommt immer auf den Kontent an, wenn man da Zeug hat was eh mal 4:2:0 war und wieder 4:2:0 werden soll und warum auch immer jetzt jedoch als 4:4:4 oder 4:2:0 vorliegt kann man auch einen Großteil der Inputdaten verwerfen. :)

    Wenn man interlactes 4k auf SD Material runterskaliert kann man sich je nach dem auch das Deinterlacen sparen, da eh keine der Informationen das Downsizen überleben. *gig*

    Cu Selur

  • Klar...

    Mein ja nur, wenn man eh nach 420 encodet und hat warum auch immer ein 444 file vorliegen, dann scheint das für normale Augen keinerlei Unterschied zu machen, wenn man im Skript gleich als erstes das sampling auf 420 runterskaliert.

    Sonst werden folgende Filter u.U. bis zum Faktor 2 runtergebremst. Das dann bewußt in Kauf zu nehmen ist wohl eher was für Gourmets, oder irgendwelche ganz speziellen Skripte, die im Verlauf irgendwo irgendwie ganz speziell die Chroma Informationen separat verwursten.

    Ich als Otto-normal Avisynthler kenn da keinen Anwendungsfall, aber es gibt ihn bestimmt...

Jetzt mitmachen!

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