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'
Code: Select all
flashback=Trim(29127,32004).FFT3DFilter(sigma=12)
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...)
