forum von fan-sub.de

die 0.85 waren total aus der luft gegriffen trotzdem bin ich beeindruckt wie gut doch xvid noch ist... ^^
Wenn du vergleichswärte brauchst ich kann die später die SSIM zwischen der byou DVD und meinem x264 encode nennen.

auf all meinen Rechnern läuft lags, da kann ich dir wohl nicht helfen :/

wenn du ne dvd mit 720x480 mit 16:9 AR hast würde _ich_ ja gar nich resizen ... okay okay für dich keine option ich weiß.
denn vergleich halt wie dues schon richtig getan hast das die resizeten xvids mit resizeten lossless oder halt avs scripten.

Zum vergleichen des ganzen videos:
einfach per Graphedit das avs mit dem Nullrenderer connected auf play drücken und warten bis es fertig ist
alternativ: mpc renderer auf null renderer und playback speed auf max stellen.

Und ja ich meine den average SSIM.

Und ja ich bin auch der meinung das wir uns bei der bitratenerspaarnis nen guten Deal gemacht haben. ^^

avis [info]: 720x480 @ 23.98 fps (90288 frames)
x264 [info]: using SAR=243/200
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
x264 [info]: slice I:929 Avg QP:12.23 size: 56213
x264 [info]: slice P:23486 Avg QP:13.19 size: 22303
x264 [info]: slice B:65873 Avg QP:15.12 size: 4157
x264 [info]: mb I I16..4: 16.7% 39.6% 43.7%
x264 [info]: mb P I16..4: 2.6% 7.3% 5.4% P16..4: 37.3% 16.2% 13.0% 0.0% 0.0% skip:18.3%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.2% B16..8: 18.0% 2.0% 4.9% direct: 4.0% skip:70.6%
x264 [info]: 8x8 transform intra:44.9% inter:39.3%
x264 [info]: direct mvs spatial:96.6% temporal:3.4%
x264 [info]: ref P 59.5% 11.5% 8.1% 4.2% 3.8% 3.2% 3.2% 2.2% 2.1% 2.2%
x264 [info]: ref B 65.2% 12.7% 6.3% 3.9% 3.2% 2.7% 2.6% 2.1% 1.3%
x264 [info]: SSIM Mean Y:0.9946837
x264 [info]: kb/s:1805.4
encoded 90288 frames, 4.96 fps, 1805.56 kb/s
Final statistics
Desired video bitrate: 1829 kbit/s
Obtained video bitrate (approximate: 1808 kbit/s )

Hm, SSIM:99.46837% ist natürlich ziemlich beeindruckend, 1805 kb/sec sind allerdings auch nicht gerade wenig. (Ich habe gerade mal die BSM5-DVD mit P-Quant:1 und Ziel 9999 kb/s encoded, dann wird die Datei für 46 Minuten Video 1.2 MB groß bei 3485 kb/sec und einem SSIM-Wert von 94.969895% - in dieser Liga kann XviD also vermutlich nicht mehr mitspielen. 92% SSIM bei nur einem Viertel der Dateigröße müssen reichen, denke ich.)
SSIM ist überhaupt ein nettes Spielzeug - damit werde ich als Nächstes mal zu messen versuchen, wieviel das Ein- bzw. Ausschalten einzelner XviD-Parameter so bringt...

Meine "Testreihe" ist inzwischen wieder vollständig - und in allen fünf DVDs "lohnt" es sich, auf 704x400px zu gehen, wenngleich sich der "Gewinn" in Grenzen hält (ich habe noch ein paar andere DVDs hier herumliegen, die werde ich auch noch im Hintergrund durchrechnen lassen):

Meine zwischenzeitliche Euphorie in Sachen SSIM ist gerade wieder am Abschwellen. Beim Vergleich der diversen Variationen, die ich bei den XviD-Parametern ausprobiert habe, zeigt sich eine Tendenz, nach welcher die SSIM-Werte fast immer analog zu den Dateigrößen ausfallen, also in Sachen Komprimierungseffizienz durchweg irrelevant zu sein scheinen.
QPel bringt dabei in meinen bisherigen Versuchen den erkennbar höchsten Unterschied in Sachen Dateigröße (verglichen etwa mit dem Ein- bzw. Ausschalten von Packed Bitstream oder Variationen der BVOP-Einstellungen, die kaum messbare Auswirkungen haben), die 3% größere Datei ohne QPel hat dabei (EDIT) einen SSIM-Wert, dessen Abstand von 100% nur 1% niedriger ist als die Version mit QPel, was so gesehen dann doch für die Effizienz von QPel spricht.

Der einzige XviD-Parameter, den ich bisher entdeckt habe, der bei gleichzeitig schrumpfender Dateigröße sogar eine Steigerung des SSIM-Wertes bewirken würde, ist GMC3 - und genau das unterstützen die Standalone-Player nicht... gnlpfts.

Für alle Metriken gilt: Sie sind ein Hilfsmittel. Nicht mehr, und nicht weniger.

Für deinen Test, DevilDoll, ist der Einsatzzweck, wie ich finde, angemessen denn dieser Test sollte ja eine Aussage über die Effizienz und nicht über die Qualität machen. PSNR, SSIM, und VQM messen die "Übereinstimmung" und nicht die "Qualität" zweier Videos. (Wenn man ein stark verrauschtes Video nimmt und nach dem Encoding eine SSIM>95% erhält ist es immer noch verrauscht. Mit Denoising ist der SSIM vllt. nur noch 75%, dafür sieht es aber, rein subjektiv, besser aus.) Bei einen Qualitätsvergleich könne die Metriken eine Aussage/Beurteilung stützen. Entscheidend ist jedoch der subjektive Eindruck ("das eigene Auge").

Vorsicht ist auch bei den verschieden Qualitäts-Optionen geboten. Bei XviD wird dies wahrscheinlich noch nicht so der Fall sein, aber ich weiß das eine x264-Parameter (bspw. VAQ) intern auch mit SSIM rechnen um eine möglichst gute Bildqualität zu erreichen. Hiermit kann man SSIM regelrecht puschen.

Packet Bitstream dürfte rein theoretisch vom Prinzip her schon keinerlei Auswirkung auf SSIM haben.

Ansonsten würde ich auch aus deinem Test als Fazit ziehen: 400p ist besser als 396p.

Beim Weglassen von Packed Bitstream bricht der SSIM-Wert seltsamerweise völlig ein (64.7%!), obwohl die Dateigröße nahezu identisch bleibt. Ansonsten bewirken die meisten XviD-Parameter Abweichungen erst bei der zweiten Nachkommastelle des SSIM-Prozentwertes und auch nur marginale Streuungen bei der Dateigröße ("adaptive Quant" schneidet im Verhältnis der beiden Werte noch recht gut ab, auch wenn die Einsparung von 2.14% Dateigröße dann 0.33% SSIM-Wert kostet, d. h. den Abstand zu 100% um 4.3% erhöht).

Mir ist bewusst, dass "Qualität" mangels zuverlässigem Referenzsystem nicht gemessen werden kann. Dass beispielsweise LanczosResize durch seine Eigenschaften, Linien nachzuschärfen, sowohl größere unkomprimiertere Dateien als auch schlechtere SSIM-Werte bei XviD-Komprimierung auf gleiche Dateigröße liefert als BicubicResize, ist so gesehen einsichtig, aber der visuelle Effekt kann trotzdem wünschenswert sein. SSIM wird mir auch nicht sagen können, ob bestimmte Degraining-Filter "gut" oder "schlecht" sind - aber es kann mir sagen, wie aggressiv solche Filter an das Quellmaterial herangegangen sind, sodass ich anschließend besser beurteilen kann, ob eine bestimmte Ersparnis bei der Dateigröße durch einen entsprechend geringen Verlust an SSIM angemessen bezahlt ist.
Für den konkreten Test ist die wesentliche Aussage der SSIM-Werte allerdings, dass die Ersparnis an Dateigröße tatsächlich auf der mod16-Idee zu basieren scheint und nicht auf einem Qualitätsverlust.

Die Abhängigkeit der SSIM-Werte von der Qualität des Ausgangsmaterial ist mir auch klar - für schlechteres Quellenmaterial als DVD-ISOs würde ich eine solche Methode gar nicht verwenden wollen. Die Silent-Möbius-Movies ließen sich von solchen DVD-ISOs mit XviD extrem schlecht komprimieren (was zum Teil auch daran liegt, dass massenhaft Explosionen, Feuergefechte und flimmernde magische Auren vorlagen); obwohl XviD für das Movie 1 nach meiner Standardmethode satte 2200 kbit/sec verbraten hat, kommt das Ergebnis gerade mal auf einen SSIM-Wert von 86%.
Um ein besseres Gefühl für die Aussagekraft der SSIM-Werte zu erhalten, werde ich noch ein paar andere DVDs durchrechnen lassen (das läuft im Wesentlichen im Hintergrund meines Rechners mit, ohne mir selbst sonderlich viel Arbeit zu bereiten) - insbesondere auch, um die Präferenz für 704x400px auf eine breitere Datenbasis zu stellen (insbesondere auf mehr unterschiedliche Quellmaterial-Qualitäten). Ich würde mich wohler fühlen, wenn ich die Aussage gleichermaßen für ältere wie neuere DVDs und für unterschiedlich effizient encodierbare Materialien übereinstimmend bestätigt sehen würde.

Um das mal kurz aufzuklären, bei ausgeschaltetem packet bitstream kann es vorkommen das das seeking nicht mehr framegenau ist, genau das scheint passiert zu sein, sodass die falschen frames verglichen werden die das Ergebnis total verfälschen.

Aikousha: SSIM ist aber atm die Metrik die dem Sehempfinden des menschlichen Auges am nächsten kommt. Und bis es einen besseren gibt vertraue ich ssim und meinen Augen.

Die Erklärung zu Packed Bitstream deckt sich mit dem, was ich in der CSV-Datei des Vergleichs-Ergebnisses finde (phasenweise 100% Abweichung).
Wer ist es dann aber, der falsch "seeked" - AviSynth selbst beim Lesen des XviD-Encodings (über "AVISource()"-Zugriff)? Bei der Anwendung von SSIM würde es ja nur darum gehen, einen fortlaufenden Stream von Frames zu produzieren... wenn schon das nicht mehr funktioniert (und zwar in einem Szenario ohne den Anspruch, realtime abgespielt zu werden), wer kann ein Video ohne Packed Bitstream dann überhaupt noch sinnvoll verarbeiten?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Ergebnisse von SSIM-Vergleichen (jeweils relativ zum unkomprimierten 27GB-Video ohne jegliches DeGraining) beim Durchprobieren verschiedener XviD-Parameter (basierend auf der DVD-ISO "BSM5" in Lanczos 704*396px, jeweils 1-pass 9999 kb/sec und jeweils nur genau 1 Parameter gegenüber dem "normal"-Set geändert, Ergebnisse sortiert nach aufsteigender Dateigröße; neben dem für Standalone-Player leider unbrauchbaren GMC3, das bei sogar steigendem SSIM-Wert knapp 2 MB einsparen würde, und QPel, das für 0.082% weniger SSIM ordentliche 9.7 MB einspart, schneidet noch der Cartoon Mode relativ günstig ab, der für 0.209% weniger SSIM immerhin auch 9.4 MB einspart und dabei mehr herausholt als der Adaptive Quant; weitere plausible Variationen fallen mir nicht mehr ein, ich werde aber noch mal mit pQuant1 und XviD-2pass versuchen, gezielt 941kb/s herzustellen und dafür den SSIM zu messen, um zu sehen, was pQuant1 bei gleicher Dateigröße bewirkt):

Aikousha wrote:Packet Bitstream dürfte rein theoretisch vom Prinzip her schon keinerlei Auswirkung auf SSIM haben.

Devil Doll wrote:Beim Weglassen von Packed Bitstream bricht der SSIM-Wert seltsamerweise völlig ein (64.7%!), obwohl die Dateigröße nahezu identisch bleibt.

eXtreme wrote:Um das mal kurz aufzuklären, bei ausgeschaltetem packet bitstream kann es vorkommen das das seeking nicht mehr framegenau ist, genau das scheint passiert zu sein, sodass die falschen frames verglichen werden die das Ergebnis total verfälschen.

eXtreme hat es schon gut erklärt. Was ich sagen wollte war: Es ist egal ob die Frames a->b->c->d oder a->c->b->d abgespielt werden. Auf die Kompression hat das keine Auswirkungen, auf SSIM sehr wohl (da ja die Reihenfolge der Frames nicht mehr stimmt, und damit die falschen Frames verglichen werden).
(Notiz an mich: Ausführlichere Erklärungen ^_^*)
___

Devil Doll wrote:wer kann ein Video ohne Packed Bitstream dann überhaupt noch sinnvoll verarbeiten?

Bis jetzt hab ich noch nichts gehört, wo deaktiviertes "Packet Bitstream" am PC zu Abspiel-Problemen geführt hätte. Bei SAPs könnte das wieder anders aussehen.
__

Eine sehr empfehlenswerte Lektüre ist das Standardwerk für XviD: Selurs Wissenswertes rund um XviD
___

eXtreme wrote:Aikousha: SSIM ist aber atm die Metrik die dem Sehempfinden des menschlichen Auges am nächsten kommt. Und bis es einen besseren gibt vertraue ich ssim und meinen Augen.

Ja, SSIM ist neben VQM eine sehr "intelligente" Metrik. Mir geht es auch nicht darum, diese zu verteufeln; im Gegenteil, ich benutze diese selbst sehr gerne. Ich möchte jedoch auch etwas kritischer darauf hinweisen das sie kein "Allheilmittel" sind, für alle die diesen Thread lesen (werden). Und ich denke das ist uns gut gelungen.
___

Vielen Dank für deine Mühe, Devil Doll.

Aikousha wrote:Bis jetzt hab ich noch nichts gehört, wo deaktiviertes "Packet Bitstream" am PC zu Abspiel-Problemen geführt hätte. Bei SAPs könnte das wieder anders aussehen.

Bei Iriya no Sora ist die letzte Episode als einzige ohne Packed Bitstream encoded worden, und prompt wurden damals im Forum Abspielprobleme gemeldet (leider weiß ich nicht mehr, ob diese sich ausschließlich auf SAPs bezogen - auf meinem eigenen SAP treten diese Probleme zudem nicht auf).

Selurs XviD-Dokument habe ich natürlich gelesen, aber es ist doch etwas anderes, die Auswirkungen bestimmter XviD-Parameter in einem konkreten Einsatzfall selbst messen zu können, als dort lediglich nachzulesen, dass Selur zu bestimmten Parameterwerten "neigt" (zumal er an vielen Stellen schreibt, bestimmte Parameterkombinationen nie ausprobiert zu haben).
Ich fühle mich einfach wohler, wenn ich bestimmte Dinge selbst ausprobiert und dabei eigene Erfahrungen gesammelt habe. Gerade deshalb empfinde ich diesen Thread auch nicht als "Mühe", sondern vielmehr als eine Art "betreutes Praktikum", durch welches ich etwas mehr Erfahrung im Umgang mit Encoding sammeln darf - und in diesem Sinne gebe ich unsere Erkenntnisse dann auch gerne an die Mit-Leser weiter.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Eine These, die ich noch im alten Forum mal aufgeschnappt hatte (IIRC von TheDeath) lautete, ein minimaler Quant von 1 für P-Frames sei im Wesentlichen Platzverschwendung. Bislang bin ich mit der Methode, den minQuant für P-Frames auf 2 zu setzen und ansonsten XviD einfach machen zu lassen (sprich: 1-pass mit Ziel 9999kb/sec, also "nimm Dir, soviel Du brauchst"), auch meistens zu ordentlichen Ergebnissen bei akzeptabler Dateigröße gekommen (ausgenommen die bereits erwähnten Silent-Möbius-Movies).
Mit SSIM als Instrument bin ich nun möglicherweise in der Lage, eine quantitative Aussage über die Effizienz von P-Frames mit einem Quant von 1 zu machen. Meine Idee dazu lautet: Ein Ausgangsvideo zunächst mit min-P-Quant:2 und 9999kb/sec encoden, anschließend mit min-P-Quant:1 auf genau diejenigen kb/s-Rate zu zielen, die beim ersten Durchgang entstanden ist (im Beispiel 941kb/sec), und zuletzt die SSIM-Werte der beiden (praktisch identisch großen) Dateien zu vergleichen. Dabei habe ich den zweiten Durchgang zweimal laufen lassen, einmal mit 1-pass- und einmal mit 2-pass-Encoding (tatsächlich sogar ein paarmal mehr, weil XviD die eingestellte kb/s-Größe anscheinend immer knapp unterbietet und ich das "Ziel" jeweils eine Idee höher einstellen musste, um die Bandbreite des ersten Versuchs auf 1 kb/s genau zu treffen), sodass ich also am Ende drei Versionen zum Vergleich hatte.
Eine logische Erwartungshaltung wäre für mich, dass 2-Pass etwas bringen muss, denn bei 1-pass muss XviD bei "frühen" Teilen des Videos raten, wieviel Bandbreite es sich leisten kann, während es bei 2-pass die Statistik-Informationen aus dem ersten Durchgang dazu nutzen kann. Die spannende Frage war also nur, ob der 2-pass-Durchgang mit P-Quants der Größe 1 und Bandbreitenbegrenzung es schafft, die "simple" Methode mit min-P-Quant:2 bei gleicher Dateigröße beim SSIM-Wert zu schlagen - und wenn ja, wie deutlich. Zum Vergleich habe ich auch noch angegeben, wie groß und wie "gut" ein Encoding mit min-P-Quant:1 und ohne Bandbreitenbeschränkung werden würde, auch wenn diese Methode aufgrund exzessiven Platzbedarfs (hier: 1.2 GB für 45 Minuten Material) in der Realität keine Bedeutung haben würde - sie zeigt aber, wieviel Information (d. h. Ähnlichkeit zu den 27 GB unkomprimiertem Quellmaterial, gemessen in SSIM) durch den generellen Verzicht auf min-P-Quant:1 verloren geht.
Und das Ergebnis sieht folgendermaßen aus: Die Verwendung von P-Quants der Größe 1 kann ein Encoding ganz ohne solche Quants tatsächlich hauchdünn schlagen (um 0.13 SSIM-Punkte bei 0.03808% mehr Platzbedarf), während der 1-Pass-Durchgang mit gleicher Dateigröße um volle 2.2 SSIM-Punkte schlechter abschneidet (was man ggf. durch Feintuning der Reaktionsgeschwindigkeits-Parameter in XviD ein bisschen reduzieren könnte, aber das traue ich mir nicht zu und es würde das Verfahren auch nicht "retten"). So gesehen erscheint mir der Verzicht auf P-Quants der Größe 1 alles in allem sinnvoll, um ohne Rechnerei auf ein dem Informationsgehalt des Rohmaterials angemessen gutes Ergebnis zu kommen, aber wer bei Encodings auf bekannte Dateigrößen zielt (z. B. 4483 MB / 26 Episoden), scheint mit P-Quants der Größe 1, Bandbreitenlimit via XviD-Taschenrechner sowie 2-Pass-Encoding nicht nur am zuverlässigsten diese Größen zu erreichen, sondern gleichzeitig auch noch mit einem minimal höheren SSIM-Wert belohnt zu werden.
Theoretisch könnte ich jetzt noch die Version mit min-P-Quant:2 und 9999kb/sec als 2-Pass-Encoding durchlaufen lassen. Allerdings wäre meine Erwartungshaltung, dass das nichts bringen sollte, da XviD eigentlich mit den Statistik-Informationen in diesem Fall nichts anfangen können sollte, weil es ohnehin Bandbreite verschwenden darf, soviel es will, ohne dem Encoding-Ziel jemals nahe zu kommen...?

"packet bitstream" ist im prinzip nichts anderes als eine andere variante b-frames in avis zu speichern. Es sollte die kompatibilität erhöhen da es selbst alten hardware decodern erlaubt mehr als 1 konstruktiven bframe flüssig abzuspielen.
Allerdings funktionieren gaaanz alte MT 13XX Chipsätze gar nicht mit packet bitstream (was man mit dem entfernen des packet bitstream mit dem mpeg modfier beheben könnte). Also sollte man "pb" immer anmachen, sollte jemand wirklich nen so alten player haben kann er selbst den stream "unpacken".


Mögliche lösung beim bframe decoder lag: neustes ffdshow tryout installiert haben, vfw optionen-->xvid auf libavcodec umstellen(untested, hint by sharktooth)

ACHTUNG:
Es kann sein das der libavcodec decoder ÜBERALL leicht bessere/schlechtere SSIM werte als der XVID nativ encoder hat weil libavc afaik einen anderen idct algo verwendet.

So, alle hier herumliegenden 16:9-DVDs durchgerechnet. 704*400px wird beim XviD-Komprimieren in allen Fällen kleiner als 704*396px, wenngleich die Einsparung jeweils weniger als 1% beträgt, und bei den beiden letzten DVDs fällt dabei sogar der SSIM-Wert etwas höher aus.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Die 4:3-DVDs sind für diesen Test nicht nutzbar, aber ich werde auch für diese mal die SSIM-Werte für mein Standard-Komprimierungsverfahren messen, um mein Gefühl dafür zu verbessern, wie normal 92% SSIM denn so sind bei "handelsüblichen" Dateigrößen und "zeitgemäßem" DVD-ISO-Material.

Was ich auch mal testen wollen würde, ist, wie aggressiv diverse DeGraining-Funktionen an das Original-Material herangehen. Dabei würde mir helfen, wenn erfahrene Encoder mir Tips geben könnten, womit sie denn so gegen Rauschen und ähnliche Bildfehler im Originalmaterial vorgehen; meine eigenen Erfahrungen beschränken sich auf simples "RemoveGrain()" mit diversen Stufen als Parameterwert ("2" ist sehr defensiv, spart aber kaum Dateigröße - das nehme ich normalerweise; "4" ist ziemlich aggressiv gegenüber dünnen Linien, würde aber stärker komprimieren).

eXtreme wrote:"ACHTUNG:
Es kann sein das der libavcodec decoder ÜBERALL leicht bessere/schlechtere SSIM werte als der XVID nativ encoder hat weil libavc afaik einen anderen idct algo verwendet.

In ffdshow kann man unter "Decoder options" die IDCT auf "auto" (falls man die libav statt libxvid verwendet) stellen, dann erkennt ffdshow die IDCT anhand des FourCC. Ob diese allerdings auch 100%ig identisch zur XviD IDCT ist, kann allerdings nur ein Blick in den Quellcode verraten. Auf der sicheren Seite ist man also auf jeden Fall mit den nativen XviD-Decoder.
___

Als Experiment und theoretisch Überlegung, finde ich deinen Test interessant; persönlich würde ich dazu aber niemandem Raten. Wenn man den Encoder künstlich begrenzt, muss man auch ganz genau wissen, was man tut. (Und ich persönlich kenne mich dafür noch zu wenig mit DCT aus.) Ich bin eher der Meinung, dem Encoder alle Freiheiten zu gewähren, und ihn dafür an anderer Stelle besser zu regulieren. Leider ist XviD an dem Punkt nicht so Einstellungsfreudig wie x264, wo sich die Beziehung zwischen I-, P und B-Frames feintunen lassen, ohne ihren Quantizer zu begrenzen (was ich persönlich für die eleganter Variante halte, die allerdings auch nicht ganz einfach ist).
___

Erfahren bin ich zwar nicht, aber ich lasse dich gerne an meinem Wissen teilhaben.
Beim Denoising unterscheidet man grundsätzlich zwischen zwei Arten: temporal (zeitlich) und spatial (räumlich). Bei temporalen Denoisern wird auf Noise entlang der Zeitachse geachtet. Soll heißen, der Denoiser schaut sich ein* Pixel im aktuellen Frame relativ zu dem Pixel im vorhergehende (und auch nachfolgende) Frame(s) an. Spatiale Denoiser schauen sich nur für jedes* Pixel im aktuelle Frame die Nachbarpixel an. Als dritte Gruppe gibt es noch Denoiser, die beide Eigenschaften verbinden: temporal-spatial (oder auch spatial-temporal, werden auch 3d-Denoiser genannt).
* es wird natürlich (meist) nicht jedes einzelne Pixel betrachtet sondern eine "Pixelgruppe", also Blöcke.

Zu den "einfachen" Denoisern zähle ich: (einfach deshalb, weil sie v.a. schnell sind)
* DeGrainMedian (temporal-spatial)
* RemoveGrain (spatial)

Zu den "schweren Geschützen" zähle ich: (die auch einiges an CPU-Performance fressen)
* mvdegrain3 (temporal-spatial)
* dcttest (temporal-spatial)
* fft3dfilter (temporal-spatial)

DEN Denoiser gibt es (leider?) nicht. Jeder Denoiser hat seine Vor- und Nachteile. Neben denen die ich aufgelistet habe, gibt es noch jede Menge andere; ein Blick auf Warpenterprise oder ins AviSynth-Wiki genügen .

Ansonsten lässt sich nur noch sagen: Jetzt kommen wir langsam in den Bereich des Filterns. Und da gilt das, was Meister Didee gerne sagt: "You lose here, you win there" (wie du ja schon an RemoveGrain erfahren hast)

Aikousha wrote:Wenn man den Encoder künstlich begrenzt, muss man auch ganz genau wissen, was man tut. ... Ich bin eher der Meinung, dem Encoder alle Freiheiten zu gewähren, und ihn dafür an anderer Stelle besser zu regulieren.

Und was wäre diese "andere Stelle"? (Filtern?)

Aikousha wrote:DEN Denoiser gibt es (leider?) nicht. Jeder Denoiser hat seine Vor- und Nachteile. Neben denen die ich aufgelistet habe, gibt es noch jede Menge andere; ein Blick auf Warpenterprise oder ins AviSynth-Wiki genügen .
Ansonsten lässt sich nur noch sagen: Jetzt kommen wir langsam in den Bereich des Filterns. Und da gilt das, was Meister Didee gerne sagt: "You lose here, you win there" (wie du ja schon an RemoveGrain erfahren hast)

Mir ist klar, dass es keinen "besten" Denoiser geben wird; dennoch wird es "bessere" und "schlechtere" geben (wenn ich CPU-Leistung als "Preiskomponente" mal ausblende). Mein Problem ist im Wesentlichen, dass ich die "Qualität" eines Filters nicht definieren kann, weil SSIM dafür nicht wirklich taugt (Beispiel Lanczos vs. Bicubic aus dem Testergebnis des vorherigen Postings: Lanczos erzeugt Dateien, die sowohl schlechter XviD-komprimierbar sind als auch bei dieser der Komprimierung niedrigere SSIM-Werte bei gleichen XviD-Einstellungen erzielen - allerdings aufgrund seiner Nachschärfung von Linien, die für sich genommen ein wünschenswerter Effekt bei Animes ist, was sich aber nicht sinnvoll quantifizieren lässt).

Aber falls ich messen könnte, dass beispielsweise ein guter 3D-Denoiser im Vergleich zum Primitiv-RemoveGrain einen besser komprimierbaren Output bei gleichzeitig mindestens gleich hohem SSIM-Wert relativ zum Ausgangsmaterial liefern würde, könnte dies ein Grund für mich sein, RemoveGrain auszumustern.
Denn bei den im Vergleich zu H.264 lächerlich kurzen Encoding-Zeiten von XviD (selbst auf meinem Uralt-PC nur etwa in der Größenordnung der Abspieldauer des Videos) halte ich CPU-Zeit generell für keine knappe Ressource, zumal die Filterung ja nur einmalig während der DVD-Vorverarbeitung abläuft und ich deren Ausgabe verlustfrei komprimiert bis zum Release auf der Festplatte vorrätig halten kann.

Generell fällt Filterung allerdings eigentlich in einen Bereich, von dessen Sinnhaftigkeit ich nach wie vor nicht überzeugt bin, gerade weil jedes neue Video anscheinend einen immer wieder neuen, individuellen Ansatz zur "angemessenen" Filterung erfordert. Mein "Test" sollte als Ergebnis haben, eine überzeugende Bestätigung für den mod16-Ansatz zu liefern, damit ein Encoder an dieser Stelle ein "Patentrezept" nutzen kann, ohne dafür eigene Zeit zu verschwenden; im Bereich der Filter scheint ein solcher Pauschal-Ansatz grundsätzlich unmöglich zu sein.
Das ist auch ein Hauptgrund, weshalb ich bisher mechanisch "RemoveGrain(2)" verwendet habe: Es schadet nichts, hilft ein kleines bisschen und kostet mich nicht die Zeit für endlose Experimente, um irgendwo noch ein bisschen Qualität herauszuschinden. Wenn ich bei einem "besseren" Filter wie etwa fft3dfilter (der mir bereits verschiedentlich empfohlen wurde) jedes Mal ein Dutzend Parameter feintunen muss und dazu an jeder Episode eine Woche lang herumbasteln muss, dann hat er für mich seinen Zweck verfehlt. Ich will nicht diejenige Arbeitszeit, die ich zuvor bei der Nicht-Verwendung von Yatta durch den Einsatz von tfm() und tdecimate() erfolgreich eingespart habe, dann wieder in die Filterung stecken.
Angesichts der Qualität von heutigem DVD-Ausgangsmaterial bin ich auch sehr am Zweifeln, ob sich die in den Filter-Prozess gesteckte Arbeit wirklich rechnet. Sollte ein Encoder heute immer noch im Wesentlichen in Begriffen wie "Aufbesserung schauerlicher VHS-Rips" denken? Ich würde jedenfalls immer versuchen, den Quantensprung bei der Qualität im Bereich des Raw-Providing zu erzielen und nicht im Bereich des Encoding... aber ich mache ja auch keine Speedsubs zwei Wochen nach TV-Airing in Japan (wovon dann natürlich nur TV-Rips in mehr oder weniger undefinierter Qualität im Umlauf sind), weshalb ich es mir üblicherweise leisten kann, zu warten, bis die japanischen DVDs erschienen sind, und dann die ISOs aus Share einzusammeln.

Wobei Ausnahmen sicherlich die Regel bestätigen: Bei den DVD-ISOs zu Iriya no Sora liefert mein Standard-Encoding-Verfahren angesichts der massiven stilistischen Unterschiede zwischen den einzelnen Episoden (u. a. ein mehrere Minuten langer Rückblick auf vergangene Ereignisse mit absichtlich nebulösen/flimmernden Bildern, für welche XviD trotz Verbot von Quant-1-P-Frames von sich aus gerne >6000kb/s Bandbreite investieren möchte) geradezu grotesk unterschiedliche Dateigrößen (Abweichungen von >200% Dateigröße zwischen den Episoden, d. h. 118 bzw. 371 MB) bei nahezu identischen SSIM-Werten von jeweils wieder um die 92%... hm. Da wird wohl ohne starke separate Filterung (Weichzeichner? An dieser Stelle wird eine ungeheuere Informationsmenge im Video verbraten, die aber nur bewirkt, dass die eigentliche Information der Szene bereits im Original-Material kaum zu erkennen ist) dieser Szene nichts zu reißen sein (eine XviD-Zonendefinition mit lokaler Qualitätsabsenkung reicht selbst bei forciertem Quant von 31 nicht aus, um das Problem auch nur halbwegs in den Griff zu bekommen, zumal die ganze Episode deutlich Action-lastiger ist als der Rest der Serie und viel mehr Bewegung enthält; wie stark der SSIM-Wert abfallen würde, wenn ich mit XviD-2pass einfach auf "handelsübliche" 200 MB zielen würde, und wie sich dann die Bandbreite über die Episode verteilt, ggf. zu Lasten der normalen Szenen, das habe ich noch nicht ausprobiert).

Dein Posting hier hat mir allerdings schon mal klar gemacht, dass RemoveGrain im Gegensatz zu anderen Filtern gar nicht den mächtigsten (und derzeit wohl allgemein verwendeten) Ansatz bei der Filterung verfolgt (sodass ich zumindest DeGrainMedian mal ausprobieren sollte, das in Sachen Preis/Leistungs-Verhältnis vermutlich überlegen sein dürfte).
Überhaupt liest sich Deine Erklärung so schön, dass man sie mit wenigen zusätzlichen Links auf weiterführende Literatur fast schon direkt als Fansub-Wiki-Artikel verwenden könnte...

- - - - - - - - - - - - - - - - - - - - - - - - -

EDIT: Diese Filter sind spannender, als ich gedacht hatte: Tatsächlich bringt brutales Glattbügeln der genannten Flashback-Szene mit dem 'Holzhammer'nicht nur deutliche Einsparungen für die Szene selbst (welche XviD nun mit 1150 kb/s encoded nach zuvor 6060 kb/s), es verhindert auch, dass XviD-1pass mit 9999kb/s beim Encoden völlig durcheinander kommt (wie beim ersten Versuch, dort vielleicht wegen der sprunghaft wechselnden Videoqualität?). Jedenfalls liefert XviD nach diesem Eingriff brav 167 MB Videostream für die gesamte Episode ab (nach zuvor 371 MB - die verrauschte Szene selbst ist dabei von 91 MB auf 17 MB geschrumpft, macht also nur 36% der gesamten Einsparung aus), bei auf den ersten Blick tadelloser Bildqualität - recht so. (Jetzt noch schnell SSIM messen, auch wenn das nach dem "Bügeln" natürlich ein unfairer Vergleich werden wird...)

Aikousha wrote:Zu den "einfachen" Denoisern zähle ich: (einfach deshalb, weil sie v.a. schnell sind)
* DeGrainMedian (temporal-spatial)
* RemoveGrain (spatial)

Zu den "schweren Geschützen" zähle ich: (die auch einiges an CPU-Performance fressen)
* mvdegrain3 (temporal-spatial)
* dcttest (temporal-spatial)
* fft3dfilter (temporal-spatial)

Angeregt von dieser Liste habe ich mal an einer konkreten DVD (Iriya no Sora Episode 4 - viele dunkle Szenen, einige Action-Szenen mit viel Bewegung, keine "künstlich verrauschten" Szenen) ein bisschen herumgefiltert (automatisch im Hintergrund laufen lassen) und die Ergebnisse via SSIM mit dem ungefilterten Original verglichen - und zwar sowohl als unkomprimiertes Video als auch als anschließend XviD-komprimiertes Video (mit jeweils identischen XviD-Einstellungen, genau wie bei allen vorherigen Tests).

Im Vergleich zu RemoveGrain, das ich so einigermaßen kenne (Parameterwert "2" ist ganz vorsichtig, "4" ist hyper-aggressiv, "8" der persönliche Favorit des Programmierers laut Handbuch), habe ich mal fft3dfilter ausprobiert, weil das anscheinend allgemein belobigt wird und zudem zwar unzählige Parameter hat, aber im Wesentlichen wohl der "sigma"-Parameter aussagt, wie "aggressiv" der Filter arbeiten soll (alles Übrige habe ich also auf Defaultwert gelassen). Da die Readme-Datei sigma-Werte zwischen 1.5 und 2.5 für "Normalfälle" empfiehlt, habe ich mal diese beiden Werte sowie den Mittelwert 2.0 ausprobiert, wobei höhere Werte mehr Veränderung am Bildmaterial bewirken.

Natürlich mag eine Anwendung auf ein einziges Video nicht repräsentativ sein. Aber einen gewissen Trend zu FFT3D glaube ich aus den vorliegenden Daten schon ablesen zu können:

• Bei unkomprimierten Daten, also der reinen Filterwirkung, ist RemoveGrain(2) etwas "vorsichtiger" als alle drei FFT3D-Varianten (es erreicht den besten SSIM-Wert aller Versuche), während bereits RemoveGrain(8) deutlich stärkere Abweichungen vom Original bewirkt als alle drei FFT3D-Varianten und RemoveGrain(4) - der "Linienzerstörer" - geradezu wie die Axt im Walde vorgeht.
• Noch deutlicher zeigt sich die exzellente Vorstellung von FFT3D, wenn man die jeweiligen Filter-Ergebnisse dann XviD-komprimiert - ich vermute mal, weil nun erst die "temporale" Komponente des Filterns so richtig zur Geltung kommt, da XviD ja im Wesentlichen Veränderungen encodiert und nicht mehr Vollbilder. Nun nämlich fällt RemoveGrain(2) auf den dritten Rang nach SSIM zurück (obwohl alle drei FFT3D-Varianten deutlich kleinere Dateien erzeugen!), während RemoveGrain(4) trotz seines aggressiven Vorgehens noch nicht mal das am besten komprimierbare Video erzeugt (bei der Dateigröße schlechter als FFT3D 2.0, das eine nach SSIM weit überlegene Qualität abliefert) und RemoveGrain(8) zu meinem Entsetzen nach der XviD-Komprimierung sogar eine deutlich größere Datei erzeugt als das völlig ungefilterte Material und trotzdem nach SSIM "versagt" hat.
• RemoveGrain(2) bewirkt bei einem Verlust von 1.2% SSIM-"Qualität" gegenüber dem ungefilterten Material eine Einsparung von 5.44% bei der XviD-komprimierten Datei; alle drei FFT3D-Varianten liegen mit Einsparungen von 8.48%, 10.28% bzw. 11.61% und gleichzeitig sogar noch besseren SSIM-Werten (ausgenommen die am stärksten einsparende FFT3D-2.5-Variante) deutlich günstiger.

Womit RemoveGrain(2) bei mir bis auf Weiteres ausgemustert sein dürfte (denn weder mit FFT3D 1.5 noch mit FFT3D 2.0 kann es auch nur ansatzweise konkurrieren)... und sooo lange dauerte das Filtern einer DVD mit 30 Minuten Material nun auch wieder nicht (60 statt 20 Minuten, jeweils inklusive Lesen&Schreiben von 17.2GB Videomaterial). Bei nur 1% geringerem SSIM-Wert immerhin 10% Dateigröße durch Filtern einzusparen, das ist ja nicht sooo schlecht.

Wenn du Lust und Zeit hast würde mich mal der gleiche Test zwischen FFT3D - Convolution3D - Deen interessieren *g*
Btw: Schön das du FFT3D jetzt nutzt xD


Und wenn einer mich eventuell zu den Vor/Nachteilen von Spline36 aufklären könnte wär ich recht froh xD

Gerne. Welche Parametereinstellung für diese Filter schlägst Du vor?

Von Convolution3D finde ich spontan nur 5 Jahre alte Versionen (und noch dazu nur eine Beta-Version, die AviSynth-2.5-tauglich wäre, die ReadMe-Datei meint aber unter "known problems": "Temporal influence currently disabled." - macht das dann noch Sinn).

Die "aktuelle" Deen-Version ist auch schon fast drei Jahre alt, und bei der verstehe ich die Auswirkungen der einzelnen Parameter nicht.

Kaoru_Battlemuffin wrote:Wenn du Lust und Zeit hast würde mich mal der gleiche Test zwischen FFT3D - Convolution3D - Deen interessieren *g*
Btw: Schön das du FFT3D jetzt nutzt xD

Ich würde eher etwas zeitgemäßere Filter wie FRFun oder dfttest vorschlagen.

Naja mich interessiert halt unter anderem einfach n vergleich zwischen alt + neu :\

Soulhunter@Doom9 wrote:FRFun3b(T,Tuv,S)
The first parameter "T" is the luma threshold the second "Tuv" the chroma threshold (both are floats). As most sources have less chroma noise than luma noise its a good idea to keep the chroma threshold lower than the luma threshold! The last parameter "S" is the subsampling: More subsampling = less processing = faster, but also less precise! Its a "speed -vs- quality" trade...

Im Doom9-Thread wird nur sehr vage auf sinnvolle Parameterwerte eingegangen - Vorschläge (speziell für Animes mit relativ hochwertiger Source, also DVD-ISO)? Wäre das hier eine Liste sinnvoller Parameter-Einstellungen? (Abgesehen davon, dass es Wochen dauern würde, diese bei mir abzuarbeiten, weil ich 40000 Frames verarbeiten lasse statt 5000, anschließend nochmal XviD-komprimiere und dann zweimal SSIM laufen lasse; der Versuch, vial SSIM meine fehlenden Encoderaugen zu simulieren, macht mir allerdings durchaus Spaß.)

FRFun3b ist sehr langsam, das Filtern würde doppelt so lang dauern wie bei meinen FFT3D-Tests (2 Stunden für 30 Minuten Anime-Material; FRFun7 mit Defaultwerten ist eine Idee schneller, das wird etwa 90 Minuten laufen).
Die Readme-Datei erklärt für FRFun3* nicht mal die Defaultwerte der Parameter (FRFun3d hat den "Subsampling"-Parameter nicht mehr, FRFun7 hat dann überhaupt wieder ganz andere Parameter...).
Die ganze FRFun-"Produktreihe" (FRFun7 scheint "Stand der Technik" zu sein) scheint zudem nur spatial zu filtern, nicht temporal - richtig? Insofern wäre es eigentlich doch eine Überraschung, wenn sie mit FFT3Dfilter mithalten könnte. Überhaupt liest sich der Doom9-Thread insofern frustrierend, als dass der Autor unbekannt ist, der Quelltext nicht zugänglich und offensichtliche Bugs nicht gefixed werden... hm. FRFun* klingt mir irgendwie nach Sackgasse (oder sogar Thema verfehlt, weil nicht temporal filternd).
Zudem macht FRFun* laut Doom9-Thread zusätzliche sinnlose Zugriffe auf Frames, in Vorbereitung einer temporalen Filterkomponente, die dann aber gar nicht implementiert wurde - das erklärt, wieso dieser Filter so unglaublich viel CPU-Zeit und Arbeitsspeicher frisst: Er ist einfach schrottig implementiert und eine völlige Code-Baustelle.

Kaoru_Battlemuffin wrote:Naja mich interessiert halt unter anderem einfach n vergleich zwischen alt + neu :\

Sag mir pro Filter zwei konkrete Parametersätze, mit denen Du eigene Erfahrungen hast (einen "vorsichtigen" und einen "etwas aggressiveren"), dann lasse ich die gerne auch mal durchlaufen. Was ich mangels eigener Erfahrung nicht kann, das ist Parameterwerte raten; ich könnte jeden Filter natürlich einfach mit seinen Defaultwerten laufen lassen, aber inwiefern die dann ausgerechnet für Animes etwas taugen, das weiß der Himmel...

In der Readme-Datei zu Convolution3D stehen immerhin symbolische Parameterwerte "animeHQ", "animeLQ" bzw. "animeBQ" drin - der Autor scheint sich über das Thema also zumindest Gedanken gemacht zu haben. Hm, dann probieren wir die mal aus... (und das ist zumindest mal ein schneller Filter, in der Größenordnung von RemoveGrain, also so um die 20 Minuten für 30 Minuten Material bei "animeHQ")

Deen scheint laut Readme-Datei mehrere Methoden zu unterstützen - die erste davon soll Convolution3D ziemlich ähnlich sein, die beiden anderen sind Eigenerfindungen des Autors und im Betastadium (und dann kam drei Jahre lang nichts mehr nach)... hm.

Einige Stunden später:

Deen unterstützt alleine schon vier verschiedene Filterverfahren: "c3d" (soll ähnlich wie Convolution3D" arbeiten, deshalb der Name), "a2d" (eigener 2D-Algorithmus), "a3d" (eigener 3D-Algorithmus) und "m2d" ("msoften2 / 21x21 emulation", noch im Alpha-Stadium).
Da wir Convolution3D schon selbst in der Testreihe mit drin haben und 2D-Algorithmen wenig verheißungsvoll aussehen (CPU-Zeit ist bei mir keine knappe Ressource), werde ich mich hier mal auf die "a3d"-Eigenerfindung beschränken (und ggf. an den Parametern drehen, wobei die beiden Thresholds wahrscheinlich die Filterqualität und der Radius die Laufzeit maßgeblich beeinflussen dürften - richtig?).

Bei dfttest sieht es ähnlich aus - das ist auch nicht ein Filterverfahren, sondern eine ganze Fülle davon, und ich weiß gar nicht, wo man da sinnvoll anfangen sollte. Auf jeden Fall wohl mit temporalen Blocks, aber mit welcher Überlappung und wie groß? Per Default ist die temporale Suche abgeschaltet, aber einfach "einschalten" geht auch nicht, da muss man schon genau beschreiben, was man eigentlich tun will... und mindestens am "sigma" wird man ja wohl auch noch drehen wollen. Benutzerfreundlich ist irgendwie anders, fürchte ich.

Convolution3D schlägt sich angesichts seiner kurzen Laufzeit (auf Augenhöhe mit RemoveGrain) und seines enormen Alters noch ganz achtbar. Es filtert bei Verwendung der vordefinierten Parametersätze für Animes extrem vorsichtig, erreicht dabei exzellente SSIM-Werte, gleichzeitig aber auch nur marginale Einsparungen bei der Dateigröße nach dem XviD-Komprimieren und verliert während des Encodings seinen SSIM-Vorsprung fast komplett wieder: "FFT3Dfilter(sigma=1.5)" schafft am Ende fast denselben SSIM-Wert wie "Convolution3D(preset='animeHQ')", reduziert dabei die Dateigröße aber mehr als dreimal so stark. Die 'animeLQ'-Variante bricht in der Komprimierungswirkung schwer ein und erreicht dabei auch noch einen schlechteren SSIM-Wert als die 'animeHQ'-Variante.
Für den praktischen Einsatz also wohl höchstens dann interessant, wenn man eine extrem hohe Datenqualität vorliegen hat. (EDIT: Und selbst dann schneidet ein ganz vorsichtiger "FFT3Dfilter(sigma=1.0)" noch besser ab.)

FRFun7 (als modernster Vertreter der FRFun-Gruppe) dürfte bei Verwendung seiner Parameter-Standardwerte als durchgefallen angesehen werden: Vor wie nach XviD-Komprimierung nach SSIM-Wert hinter sämtlichen FFT3Dfilter-Varianten, welche aber gleichzeitig deutlich kleinere Dateien produzieren. Hinzu komm dann noch die ungeheuerliche Laufzeit (trotz 2D-Filterung erheblich langsamer als FFT3Dfilter).