Bester Deinterlacing Filter???

  • OK, da ich TDeint und TempGaussMC gerne mal ausprobieren würde habe ich im Netz mal gesucht. In Sachen TDeint bin auf ein File namens smartdecimate_avisynth.zip gestoßen. Ist dass das richtige File? Und, wie binde ich die beiden am besten so ein dass ich sie auch mit StaxRip benutzen kann?

  • TDeint ist zu finden auf der AviSynth-Plugins-Seite von tritical, oder in der AviSynth-Filtersammlung von WarpEnterprises.

    TempGaussMC ist ein Import-Skript mit Funktionsdeklaration, das mehrere weitere Plugins verwendet, und in den ersten Antworten dieses Beitrags verlinkt wurde.

  • Ich möchte an dieser Stelle noch mal YadifMod erwähnen. Kombiniert mit NNEDI2 bekomme ich damit sehr zufriedenstellende Ergebnisse.

    Die beiden benötigen Plugins findet man hier:
    http://web.missouri.edu/~kes25c/

    Code
    function YadifModNNEDI2Bob(clip src, int quality){  interpol = src.nnedi2(field=-2, qual=quality)  return src.YadifMod(mode=1, edeint=interpol)}function YadifModNNEDI2Deint(clip src, int quality){  interpol = src.nnedi2(field=-1, qual=quality)  return src.YadifMod(mode=0, edeint=interpol)}
    Code
    MPEG2Source("Foobar.d2v")
    AssumeTFF()
    YadifModNNEDI2Bob(1)

    Yadif:
    http://img43.imageshack.us/img43/4121/yadifvsnnedi22a.png

    YadifMod + NNEDI2:
    http://img3.imageshack.us/img3/1751/yadifvsnnedi22b.png

  • Oh! YadifMod mit NNEDI2 ... ganz was neues!

    Wer hat behauptet, dass es neu sei ???

    Hmm, da krieg ich aber deutlich andere Ergebnisse :hm:

    http://www.mediafire.com/file/im45jyzmy…fmod_needi2.zip

  • Hihi! Ja, klar doch. Ich zeige auf, dass Yadif einen zentnerschweren Stein *nicht* aufheben kann, TGMC aber schon. Jetzt kommst Du und protestierst, dass Yadif/Mod aber doch durchaus einen Kieselstein aufheben kann! Na toll. :D

    Deine Quelle ist die per Lowpass-Deflicker breitgematschte (mit um 50% reduzierter effektiver Auflösung) 576i-Version.
    Meine Quelle ist die 720p-Version, von der ich die 576i-Version selber gesampled und interlaced habe.

    Schau doch mal:

    Dein Zeug: .................... mein Zeug:
    http://img651.imageshack.us/i/stockholmlowpass.jpg/http://img690.imageshack.us/i/stockholmsharp.jpg/

    Das sind schon völlig verschiedene Welten, oder nicht?

    Man muss schon verstehen, mit welcher Art von Input man genau arbeitet, und was die daraus folgenden Konsequenzen sind.
    Ich geb' ja zu, dass meine (sehr scharfe und sehr detaillierte) Version nicht unbedingt der typischste aller Fälle ist. (Viele Camcorder tendieren jedoch in diese Richtung.) - Aber, um die Möglichkeiten und Grenzen von Kandidaten auszuloten, dazu braucht man schon entsprechende Aufgaben! Mit primitiven "Wieviel ist 2 + 2 ?"-Aufgaben kann man keine Tests gestalten, weil das selbst der Dümmste beantworten kann. Nein ... man muss schon schwierige Fragen stellen, um herauszufinden, wer was kann, und wer was nicht kann.


    In den Fällen wo's richtig wehtut, da arbeitet Yadif schlecht. Ziemlich egal ob original+schnell, oder das NNEDI2-langsame YadifMod.
    In den Fällen wo Yadif/Mod richtig gut arbeitet (starker lowpass) ... hoppala, da bekommt man selbst mit nem primitiven Bob() ein sehr ordentliches Ergebnis!:ani_lol: (Nur halt 10-mal schneller - NNEDI2 ist grundsätzlich langsam).

    Die Grenzübergange sind natürlich fließend:
    - Ganz oben arbeitet Yadif/Mod einfach schlecht.
    - Ganz unten arbeit Yadif/Mod technisch gut, bringt aber auch nur wenig Vorteil.
    - irgendwo in der Mitte ist ein Bereich, in dem Yadif/Mod ein bisschen was bringt, und noch nicht völlig schlecht arbeitet. Yo baby!


    Also, ich bleibe dabei. YadifMod(NNEDI2) kann "2+2=?" berechnen, braucht aber relativ lange für die Antwort. Fragen nach dem doppelten Flächenintegral kann es nicht beantworten.
    TGMC braucht für "2+2=?" zwar auch recht lange, aber es kann eben auch doppelte Flächenintegrale berechnen, und kommt auch mit Trigonometrie und Prädikatenlogik ganz ordentlich zurecht. Ausserdem berechnet TGMC selbst 2+2 viel genauer als Yadif.

    Übrigens: Zwar ist das bob-geflickere bei dem Lowpass-Qellmaterial nicht mehr so deutlich sichtbar (was ja auch der Zweck des Lowpass' ist), aber es ist immer noch vorhanden!

    Im Vergleich mit Xvid Q2 ohne Bframes (zur empirischen Vergleich betreffs "Stabilität auf der Zeitachse" - meckern zwecklos, das macht Sinn) zeigt sich etwa, dass YadifMod(NEEDI2) 53% mehr Bitrate braucht als TGMC, Bob braucht 65% mehr. Ups, Yadif hat weniger Detail als TGMC, erzeugt aber so viel mehr Datenrate? Das ist eben das immer noch unterschwellig vorhandene Bob-Geflicker.

    Das ganze nochmal, auf Basis der WischiWaschi-Quelle:

    LINK

    In der Summe: YadifMod(NNEDI2) ist etwas schneller als TGMC (aber u.U. gar nicht mal soooo viel), sieht schlechter aus, und braucht deutlich mehr Bitrate.
    TGMC ist zwar langsam, aber es nutzt die zusätzliche Zeit auch intensiver als andere Bob/Deinterlace/Filter. Der Zugewinn pro zusätzlich investierter Zeit ist größer.

  • Okay, du hast dir also selbst eine Quelle gebastelt, mit der YadifMod+NNEDI2 keine guten Ergebnisse liefert. Bleibt natürlich die Frage, in wie weit das für die Praxis relevant ist. Extra eine Quelle zurecht zuschrauben, mit der der Deinterlacer nicht zurecht kommt, ist in gewisser Hinsicht ein unfairer Vergleich. Schließlich würde man in der Praxis ja wohl die 720i oder 1080i Quelle zuerst deinterlacen und dann runterskalieren. Außerdem kann ich nicht feststellen, dass deine Version am Ende deutlich mehr Details erhält als meine (auch wenn dein Ergebnis insgesamt sehr wohl etwa besser aussieht, was ich ja auch im Übrigen niemals bestritten hab), d.h. die führst das "Lowpassing" im Prinzip nur an anderer Stelle durch. Ich hab nie behauptet dass YadifMod+NNEDI2 die besseren Ergebnisse liefert. Und ich hab auch nie die Qualität von TGMC in Frage gestellt. Nichtsdestotrotz erziele ich mit YadifMod+NNEDI2 in der Praxis sehr gut Ergebnisse. Nach meiner persönlichen Meinung deutlich besser Ergebnisse als mit Yadif alleine oder mit TDeint alleine. Nichts anderes wollte ich hier erwähnt haben! Ich wollte hier sicher keinem TGMC Verfechter auf den (virtuellen) Schlips treten ^^

  • Okay, du hast dir also selbst eine Quelle gebastelt, mit der YadifMod+NNEDI2 keine guten Ergebnisse liefert. [...] Extra eine Quelle zurecht zuschrauben, mit der der Deinterlacer nicht zurecht kommt, ist in gewisser Hinsicht ein unfairer Vergleich.


    Nö. Du unterstellst mir eine Zielsetzung, die aber nicht zutreffend ist. :)

    Der Ursprung war einmal der: Wenn man mit einem fix-und-fertig interlacten Stream anfängt, dann sind alle Tests letztlich nur eine Geschmacksfrage: Weil man dann nämlich keine Ursprungs-Referenz hat, um zu überprüfen, wie gut oder schlecht der (Bob-) Deinterlacer es geschafft hat, den ursprünglichen progressiven Inhalt wiederherzustellen.
    Also hab' ich mir ein paar progressive (HD-) Referenzen geschnappt. Die kann ich händisch skalieren und interlacen, und habe am Ende eine aussagekräftige Referenz, um das Ergebnis *vernünftig* bewerten zu können. (Anstelle von: och, das sieht ganz gut aus, das sieht nicht ganz so gut aus, dieses gefällt mir Montags etwas besser, jenes mag ich Donnerstags lieber, ...)

    Und dabei hat sich gezeigt, dass ...

    Zitat

    Bleibt natürlich die Frage, in wie weit das für die Praxis relevant ist.


    ... die Charakteristik des interlacten Materials eine große Rolle spielt. Wenn die Quelle vor dem Interlacing stark Lowpass-gefiltert wird, dann kommen alle Deinterlacer gut zurecht. Wenn nur sehr wenig oder gar nicht Lowpass-gefiltert wird, dann wird die Luft sehr dünn.

    Meine Meinung ist, dass in den meisten Fällen viel zu viel Lowpass angewendet wird. Die Grund-Idee von Interlacing ist: volle zeitliche/halbe spatiale Auflösung bei Bewegung, und: volle spatiale Auflösung bei nicht-Bewegung.
    Mit der oft üblichen sehr starken Lowpass-Filterung wird das Praxisergebnis aber schlechter gemacht: halbe spatiale Auflösung bei Bewegung, und halbe Auflösung auch bei Stillstand.

    Bin mir nicht sicher, in wie weit diese Praxis im Sinne der ursprünglichen Erfinder ist. Ich persönlich finde das jedenfalls nicht so toll. Insbesondere, wenn (ebenso üblich) dem vertikalen Lowpass mit einer vertikalen Bandpass-Schärfung nachgeschossen wird. Ein kläglicher Versuch, den Verlust an Auflösung kaschieren zu wollen ... die Auflösung ist effektiv immer noch halbiert, und obendrauf kriegt man noch hässliche Halos an horizontalen Kanten. Die objektive Bildqualität wird weiter verschlechtert, der Inhalt wird noch schlechter komprimierbar, also muss stärker komprimiert werden, also sinkt die Bildqualität noch weiter in den Keller.

    Jedenfalls, es wird ja nicht alles völlig breitgematscht. Ich habe z.B. schon so einige Camcorder-Aufnahmen gesehen, bei denen der Lowpass-Anteil angenehm gering ausfällt, die also nicht alles hoffnungslos breitmatschen.

    Es gibt also solche Quellen, und es gibt solche Quellen. Die ganze Bandbreite ist vorhanden. Es gibt nichts, was es nicht gibt.

    Deswegen bin ich der Meinung, dass mein mein Stress-Test durchaus zulässig ist. Vielleicht nicht absolut typisch, das mag ja schon sein. Aber wie gesagt: Wenn wir nur breitgematschte Quellen testen, bei denen alle Bob/Deinterlacer fast identisch aussehen, dann können wir das ganze Thema auch gleich bleiben lassen. Testen wird um so interessanter, je dünner die Luft wird. Du würdest ja auch einen FullHD-Encoding-Test @ 5000kbps gegenüber einem Test @ 100000 kbps vorziehen, oder? Bei 1mbps ist mpeg2-Encoding absolut konkurrenzfähig. Bei 5000kbps ist es das nicht. Und eben darum geht es.

    Und in diesem -übertragenen- Sinne verstehe ich auch Bob/Deinterlacer-Tests. Nicht das Testen, was sowieso alle können. Vielmehr das Testen, wo sich die Spreu vom Weizen zu trennen beginnt. :)

    Zitat

    Schließlich würde man in der Praxis ja wohl die 720i oder 1080i Quelle zuerst deinterlacen und dann runterskalieren.


    Irrelevantes Argument. Die progressiven Sequenzen sind nun mal in HD, zum Testen und veranschaulichen reicht mir SD aber völlig aus, und es geht schneller. Mit der Problematik hat das nichts zu tun.

    Mein Script fängt einfach so an:

    Code
    RawSource("F:\Video\Samples\720p5994_stockholm_ter.yuv",1280,720,"I420").assumetff()
    spline16resize(720,576)
    
    
    # mt_convolution("1","1 2 1",U=3,V=3).merge(last,xx) # simple lowpass, strength adjustable
    
    
    separatefields().selectevery(4,0,3).weave()


    Erst wird aus dem progressiven HD ein progressives SD erstellt. Das kann ja wohl so verkehrt nicht sein. Dann kann ein Lowpass durchgeführt werden, muss aber nicht. Ebenfalls OK. Anschließend wird so interlaced, wie man eben interlaced.
    Ich sehe da nichts falsches, oder absichtlich begünstigendes od benachteiligendes.

    Übrigens ist es gar nicht kompliziert, einen weniger aggressiven Lowpass zu erstellen, der ähnlich gute Flicker-Reduktion erreicht, aber weniger breitmatscht. (Man nehme einen Standard-Lowpass, erstelle einen Highpass von der Differenz, und verwende dann dieses ... erzielt 95% des gewünschten Effekts, aber 60% weniger des unerwünschten Nebeneffekts.)

    Ebenfalls möglich, und nicht übermäßig kompliziert: Ein *bewegungsadaptiver* Lowpass-Filter. (Vom Grundprinzip her: ein umgekehrtes Soothe) - Lowpass nur dort, wo er auch wirklich gebraucht wird, nämlich bei Bewegung. Bei nicht-Bewegung wird auch nicht gefiltert. Dann flackert's nicht bei Bewegung, und bei Stillstand hat man tatsächlich die volle Auflösung, so wie es sein sollte.
    (Hatte ich schon mal gebastelt, funktioniert recht brauchbar. Das hätte man bereits vor Jahrzehnten in die Producer-Lines einbauen sollen ... aber an sowas hat anscheinend niemals jemand gedacht...)


    Zitat

    Außerdem kann ich nicht feststellen, dass deine Version am Ende deutlich mehr Details erhält als meine


    Es ist nicht so überaus deutlich, weil schon so viel im Lowpass verloren gegangen ist. Aber doch, da ist schon noch etwas mehr Detail. (Mehr "echtes" Detail, im Gegensatz zu "nur" Interpolations-Ratespiel.)


    Zitat

    Ich wollte hier sicher keinem TGMC Verfechter auf den (virtuellen) Schlips treten ^^


    War auch gar nicht der Fall - ich trage keine Krawatten.;) Ich wollte nur nochmal verdeutlichen, dass die "einfachen" Methoden mit höherem Rechenaufwand nicht wirklich so dolle sind, d.h. dass der erhöhte Rechen- und Zeitaufwand oftmals nur in unverhältnismäßig wenig Ergebnisverbesserung resultiert.

    Yadif ist sauschnell, tendiert aber zu hässlicher Posterization. Beim Bobbing flackert's sowieso.

    YadifMod+NNEDI2 ist bereits sehr deutlich langsamer, hat auch durchaus ein deutlich besseres Sampling, aber für hochwertiges Bobbing ist der zugrundeliegende Yadif-Algorithmus einfach zu primitiv. Die Vorteile, die NNEDI2 mit recht hohem Rechenaufwand erreicht, neigen dazu, in den negativen Seiteneffekten der zu simplen Bob-Methode unterzugehen.

    TDeint+TMM+NNEDI2 ist auch nicht viel besser. Durch TMM wird zwar die Grenze zwischen Bewegung und nicht-Bewegung etwas weiter herausgeschoben ... aber sie wird eben nur etwas verschoben, sie wird jedoch in keinster Weise verringert. Berücksichtigt man, dass TDeint+TMM+NNEDI2 bereits ähnlich langsam wie TGMC ist (TMM ist wirklich langsam), dann liefert diese Kombo vielleicht sogar den geringsten Zugewinn im Verhältnis zum zusätzlichen Rechenaufwand.

  • Finde es angenehm, dass die Files ohne Audio sind. ;)

    Der Videoanteil zeigt: TGMC ist ziemlich ruhig, Yadif flackert recht nervös, und das schlägt sich auch in der erzielten Bitrate nieder.

    Hat jemand den SWR bestochen, damit die speziell zurechtgeschraubtes Material senden, welches TGMC gut kann, Yadif aber nicht? :floet:

    Es überrascht mich etwas, dass der Bitraten-Unterschied auch bei AVC so groß ist - hätte eigentlich erwartet, dass v.a. multi-ref den Unterschied relativ klein halten könnte. Sind aber immer noch knapp 50%, die Yadif mehr braucht. Naja, bei CRF 20-22-24 wird der Unterschied bestimmt um einiges kleiner.

    Schade eigentlich, dass meine alte Möhre die Streams nicht in Echtzeit abspielen kann - macht ca.18fps, und ruckelt ...

  • Wie reiht sieht ein Nvidia Deinterlacer (DGdecNV) eigentlich in den Vergleich ein?
    Da mir das ganze gefrickel mit den diversen Filtern zu viel wurde nutze ich diesen momentan überwiegend für meine 08/15 Encodes.
    (Zumindest bei entsprechendem Quell-Material)

    --
    Edit:
    Erstaunlich wie wenig ich von dem hier erwähnten tatsächlich verstehe :D

    3 Mal editiert, zuletzt von LigH (15. März 2010 um 16:14) aus folgendem Grund: URL von Google-Wrap befreit

  • DGDecNV ist in erster Linie ein Decoder. Das Deinterlacen fällt hier nur als nette Beigabe mit ab, und da wirst du dich voll auf die Hardware-Implementation in der Grafikkarte verlassen müssen. Zumindest habe ich noch keine Details gefunden, welche Art von Deinterlacing (Blend / Bob / MC...) tatsächlich durchgeführt wird.
    __

    Nun ja ... laut MSDN gibt es für DXVA-unterstütztes Deinterlacing mehrere Möglichkeiten. Der Grafiktreiber kann mehrere Varianten implementieren und anbieten; mindestens Bob (doppelte FPS) und die Weitergabe von progressivem Material müssen unterstützt werden. Es liegt außerdem in der Verantwortung des Grafiktreibers zu definieren, ob er für das Deinterlacing mehrere benachbarte Frames benötigt. IVTC per DXVA ist also ebenfalls möglich. Mit dem Decoder hat das Deinterlacing im Grunde wenig zu tun.

    MSDN: DXVA Video Processing

    Da DGDecNV aber CUDA verwendet, hat er wohl auch nicht viel mit DXVA zu schaffen. Müsste man also für Nvidia noch mal getrennt nachschlagen.
    __

    Anscheinend nutzt DGDecNV den Deinterlacer der PureVideo-Funktionen. Viel gibt's da auch nicht auszuwählen: Nichts, gleiche Framerate oder doppelte Framerate - letzteres ist Bobbing. Die Methode für "gleiche Framerate" wird auch nicht besonders intelligent sein, oft ist es nur ein Überblenden von Halbbildern.

Jetzt mitmachen!

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