TempGaussMC in StaxRip einbinden - bin einfach zu blöd dafür...

Zitat von Didée

Ausserdem ist auch EEDI2 darselbst nicht völlig unproblematisch. Im allgemeinen wird NNEDI2 bevorzugt.

Hier sieht man an einem Beispiel deutlich ein besseres Ergebnis mit EEDI2: http://forum.videohelp.com/threads/315725…-diagonal-lines

Fritz Photo unterstützt übrigens auch schon EEDI3. Aber wenn ich mich nicht irre (und ich irre mich nie, wenn ich mich nicht irre ... ach nee, das war Sam Hawkins), dann braucht das Teil wahnsinnig viel Rechenzeit.

Zitat von LigH

Fritz Photo unterstützt übrigens auch schon EEDI3.

Das werde ich mal antesten. Auf jeden Fall ist NNEDI2 ein Problem bei horizontalen Linien, wie auch hier zu sehen: http://forum.doom9.org/showthread.php?p=1343668#post1343668
Wenn Didée meint, NNEDI2 sei üblich, dann nur aus Geschwindigkeitsgründen.

Zitat von Lapje

Natürlich spielt Geschwindigkeit auch eine Rolle.

Ich würde ohnehin nicht 2pass kodieren, sondern mit crf 16-20. Eine genaue Zielgröße ist doch zumeist nicht erforderlich. Da dann auch der Kompressionstest entfällt, wird viel Zeit eingespart.

Moin,

Zitat

Habe ich ja auch schon rumgespielt. Nur dann komme ich in Endgrößen die jede Umwandlung sinnlos machen, weil ich am Ende vielleicht 1/5 spare...da kann ich es auch direkt so lassen...

Das hat dann aber doch gar nix mit CRF zu tun, sondern deine 2-pass-Bitrate ist deutlich niedriger - musst halt auch höhere crf-Faktoren nehmen...
..einfach mal ein paar Schnipsel probeencoden und die durchschnittliche Bitrate vergleichen.

Alternativ kann man auch mit TGMC in eine Zwischendatei encoden und DIESE dann mit 2-pass verwurschteln.

Zitat von Lapje

Nur schade dass es halt nichts irgendwo zwischen Yadif und TGMC gibt...

Ach komm! Es gibt durchaus ein paar Deinterlacer, die schneller als TGMC und nicht ganz so rücksichtslos wie Yadif arbeiten. Bereits in dem Beitrag über den "besten Deinterlacer" hatten wir beispielsweise TDeint erwähnt. Und vermutlich ist LeakKernelDeint auch nicht völlig blöd.

Und wenn man TGMC als Win32-DLL mit optimierendem Compiler programmieren würde, wäre er auch schneller als als AviSynth-Funktion.

Zitat von hdst

Wenn Didée meint, NNEDI2 sei üblich, dann nur aus Geschwindigkeitsgründen.

Schön, dass ich auch mal erfahre, warum ich etwas gesagt habe, oder was ich damit eigentlich gemeint habe! :hm:
(Hättest Du mit "...vermutlich..." einen Konjunktiv gebaut, wärst Du auf der sicheren Seite gewesen...)

Ja, EEDI2 ist deutlich erfolgreicher beim Verbinden von "zerbrochenen" Linien. Das ist absolut unbestritten. Aber es ist halt nicht alles Gold. Es kommt eben auch vor, dass EEDI2 irgendwelche Punkte verbindet, die nicht verbunden werden dürften. (Es sieht doof aus, wenn eine Bühne vorne mit kleinen Lämpchen besetzt ist, und EEDI2 macht aus den vielen kleinen Pünktchen eine Strichpunkt-Linie ... die auch noch nervös flackert, weil EEDI2 mal verbindet, dann wieder nicht, dann wieder doch, dann wieder nicht,...) Reduziert man den "maxd" Paramter so weit, dass die falsch-Verbinderei aufhört, dann hört auch das "richtige" Verbinden ganz schnell auf zu funktionieren.
Ausserdem hat EEDI2 eine ähnliche Neigung zum "Ölbild-Effekt" wie der Yadif, siehe Beispiel oben. Ist zwar weniger stark ausgeprägt, aber vom Prinzip her ganz ähnlich.
Und manchmal erkennt auch EEDI2 zu verbindende Linien nicht, obwohl es für das Auge ein offensichtlicher Fall zu sein scheint.

Und EEDI3 ist wirklich SEHR langsam, verbindet noch mehr zerbrochene Linien, macht aber immer noch die gleichen blöden Fehler mit falschen Verbindungen. Nur halt, dass er dafür sehr viel länger rechnet ....

Faustregel: jeder Filter, der irgend etwas besonders gut macht, macht irgend etwas anderes besonders schlecht.

Was da jetzt "besser" oder "schlechter" ist kann man so nicht sagen. Aber in den meisten Fällen wirkt das Ergebnis von NNEDI2 "natürlicher", während EEDI2 eher "künstlich" wirkt.

Zitat von Lapje

Aber kann es sein dass darin MVBobMod() eine bessere Qauli hat als TDeint(mode=1,NNEDI,TMM) ? Zumindest empfinde ich das Bild als ruhiger.

Das kann schon sein. Beim MVBob ist halt alles ein wenig einfacher gestrickt.

Ein Problem des MVBob ist, dass er eine direkte Feld->Feld Bewegungssuche durchführt, ohne Rücksicht auf den vorhandenen Bob-Flicker. Soll heißen: MVBob will den Bob-Flicker reduzieren, läuft aber Gefahr, dass die Bewegungssuche dem vorhandenen Flicker einfach nachfolgt.
Möglicherweise würde es dem MVBob gut zu Gesicht stehen, wenn man ihm die TempGauss-Vorfilterung aus dem TGMC einpflanzen würde. Die Vorfilterung ist ja recht schnell, im Prinzip reicht ja ein temporalsoften(1,255,255,28,2).merge(last,0.25). Allerdings muss(!) man dann auch noch die Werte für die idx-Variablen anpassen. Und ausserdem weiß ich im Moment nicht so genau, inwieweit sich MVBobmod von Scharfis originalem MVBob unterscheidet (meine mich zu erinnern, dass hauptsächlich irgendwelche Thresholds ganz jämmerlich in die Höhe getrieben wurden ... aber so genau weiß ich das nicht mehr.)

Tag zusammen,

ich hab jetzt ein paar Stunden rumprobiert und den TGMCbeta2 in Staxrip eingebunden. Im Endeffekt hab ich ein rumgefrickel produziert, was aber läuft. Ästhetisch ist es bisher nicht. In die genaue Funktion von Avisynth-Scripten bin ich nicht eingestiegen, sondern habe (bildlich gesprochen) ein Treckerrad mit ein paar herumliegenden Schrauben an ein Auto geschraubt, mit dem Effekt, das sich das Rad dreht^^

Zu Leistungsmessungen bin ich noch nicht gekommen, und bei der Rechenzeit von TGMC werd ich das mit diesem Rechner auch nicht machen. In 10 Jahren auf ein paarhundert Kernen juckt das keinen mehr...

Da, wie ich aus diesen Thread entnommen habe, Avisynth erst von der Existenz der TGMC-Funktion in Kenntnis gesetzt werden muss, und man sie danach aufrufen kann (soweit reichen meine Turbopascal-Kenntnisse noch^^) habe ich für TGMC einfach 2 Einträge im linken Staxrip-Fenster gemacht.

Einen mit der import(tgmc.avsi)-Anweisung, gefolgt vom funktionsaufruf "tgmc(batterie,von,parametern,die,ich,nicht,verstehe)"
Parameter aus Didees Vorschlag hier.

Zusätzlich hab ich die tgmc.avsi um die pluginladeanweisungen in den ersten 5 Zeilen erweitert. (ich hab da mit Bauklötzen gespielt, mit denen ich eigentlich nicht umgehen kann...)

Danach alle fehlermeldungen gegoogelt, und entsprechend behoben (irgendein mode20-Fehler, wo man eine Datei austauschen musste, und ne fehlende .dll)

Läuft soweit. Das Ergebnis einer interlaced-Quelle ist nach langer Rechenzeit (Faktor 5-8!), eine ordentlich aussehendes progressives Bild.

Fragen:

1) Kann man die Wirkung der Parameter mal erklären? Was sie tun, mit welcher Wirkung auf die Quali und den Effekt auf den Rechenaufwand. Speziell würden mich qualitativ die lokalen Ableitungen (dQuali/dParameter-i) und (dRechenzeit/dParameter-i) an der Standardeinstellungsstelle interessieren. (wer mit solch fiesem Zeug wie Avisynth umgehen kann, kann auch Mathe^^)

2) Bei der Quali hab ich allerdings Einschätzungsprobleme:
Die hier gezeigten Beispiele sind klar "pro tgmc", allerdings ist hier der tradeoff "Quali vs. Rechenzeit" auch extrem. Ich benutzte bisher Tomsmocomp, und war nicht wirklich unzufrieden, ich weiß es aber auch nicht besser. Soviel interlaced-Material gibts ja auch nicht mehr, Tendenz stark fallend.

* Wo liegt TomsMoComp (Staxrip-Standard) im Vergleich zu anderen DeIntern? "TDeint" wird immer wieder mal genannt.
* Welche DeInter lösen den tradeoff nicht ganz so radikal, wie tgmc, aber immer noch brauchbar?

3) wie zum beispiel hier zu sehen, macht NNEDI2 seinen Job auch gut. Wenn NNEDI2 nun als vorausgesetztes Plugin für TGMC ein Teil der durch TGMC durchgeführten Berechnungen ist, was macht TGMC denn mehr? NNEDI2 ist angeblich langsam, TGMC auch.

LigH:

Zitat

Und wenn man TGMC als Win32-DLL mit optimierendem Compiler programmieren würde, wäre er auch schneller als als AviSynth-Funktion.

Warum macht man das nicht? Wenn man den Algorithmus hat, kann das doch nicht so schwer sein, oder? Die Brainware ist doch schon gemacht, oder? Nicht? Kein Vorwurf, ich lerne gerne!

Das wars fürs erste.
Grüße

Mangels Zeit für 'ne ausführliche Anwort (späääter.....) verweise ich für den Moment einfach mal auf das nächste Beispiel.

Wer soll denn die Programmierung durchführen? Der Programmierer der einen Plugin-DLL, die von TGMC benutzt wird? Der Programmierer der anderen Plugin-DLL, die von TGMC benutzt wird? Der Programmierer des TGMC-Skriptes, der kein C++ kann? Ein ganz anderer Programmierer, der sich in alle (falls überhaupt) verfügbaren Quelltexte einarbeitet, bis er sie alle ins kleinste Detail verstanden hat? Alle beteiligten Programmierer gemeinsam? ... Trivial wird es jedenfalls nicht.

Es ist eben nicht ein einziger Algorithmus. Es ist eine Kombination aus mehreren. Und da ist ein AviSynth-Skript im Vergleich eher "das kleine Einmaleins". Für Didée, den Meister der UPN mit LUTs, sowieso.

Zitat von LigH

Wer soll denn die Programmierung durchführen? Der Programmierer der einen Plugin-DLL, die von TGMC benutzt wird? Der Programmierer der anderen Plugin-DLL, die von TGMC benutzt wird? Der Programmierer des TGMC-Skriptes, der kein C++ kann? Ein ganz anderer Programmierer, der sich in alle (falls überhaupt) verfügbaren Quelltexte einarbeitet, bis er sie alle ins kleinste Detail verstanden hat? Alle beteiligten Programmierer gemeinsam?

Der farbig Hervorgehobene! Der soll das machen! Jawoll!

Vor allem, und darüber hinaus: es ist ja nicht damit getan, einfach den Script-Code zu nehmen und ~ir~gend~wie~ in ein DLL-Plugin 'reinzuquetschen. Das würde nur wenig schneller laufen. Die "großen Zeitfresser" MVTools und NNEDI2/EEDI2 blieben geschwindigkeitsmäßg davon sowieso ziemlich unberührt. Den "Kleinkram" könnte man vrmtl. optimieren, die großen Brocken aber eher nicht...
Außerdem ist die ganze Geschichte einfach recht unangenehm betreffs des "internen Datenflusses/-managments". Doppelte zeitliche Relation sind aufwändig und schlecht zu optimieren (ein zeitlicher Filter, auf den ein zeitlicher Filter angewendet wird), und an den verschiedenen Neben-Ästen dieses doppelten Baumstammes sind halt auch noch nicht ganz unerhebliche Gewichte (spatiale Filter) aufgehängt. Diese Gewichte machen das "zeitliche Jonglieren" nicht gerade einfacher, rein optimierungstechnisch gesehen.

Das ist in etwa so, wie wenn ich im Keller den Schrank mit Tonnen von Vorlesungs-Mitschrieben aufmache, und bekomme den Auftrag: "schreib' das doch mal bitte ins Reine." :nein:

Ja, da wär ich aber auch für^^
Ich glaube, ich gebs auf, dort bis in die Tiefen vorzudringen und beschränke mich aufs Anwenden.

Sind meine Fragen noch auf dem Schirm? Die ersten beiden sind noch von Interesse, die dritte ist ja eigentlich geklärt.

Grüße, D

Juppa, habe das (noch) nicht aus den Augen verloren. Aber, um die Vorfreude gleich ein wenig zu dämpfen: Der Grundtenor der Antworten wird sowieso hinauslaufen auf: "es gibt kein endgültiges 'richtig' oder 'falsch' oder 'besser' oder 'schlechter'. Es gibt nur unterschiedliche Anwendungsfälle, unterschiedliche Situationen, und unterschiedliche Geschmäcker."

Das ist klar... Qualitative Aussagen, die in den meisten Fällen zutreffen, sind eigentlich das, was ich will. Du hast davon so viel Ahnung, das deine Einschätzung mehr Wahrheit enthält, als sich die meisten Menschen (mich eingeschlossen) an Wissen aneignen wollen oder können.

Ne kleine Parameterempfehlung für 90% der erreichbaren Qualität wäre auch toll. 100% perfekt muss es ja auch nicht sein. Vielleicht auch dazu schreiben, in welchen Situationen diese Einstellungen gut sind, und in welchen Situationen man davon abweichen sollte.

Im einzelnen gehts darum, die Wirkung der Parameter zu erfahren. Welchen Einfluss sie auf den Rechenaufwand haben, und welchen Effekt sie im Bild erzeugen, damit ich selbst ein bissl rumspielen kann, und nicht völlig blind an den Knöpfen drehe, ohne eine Erwartung zu haben, was nun passieren könnte, und besser darauf achten kann

Auch wäre es interessant, in welchen Fällen einfachere Deinterlacer (Tomsmocomp, Tdeint,...) auch ordentliche Ergebnisse erzielen können, und eine grobe Einschätzung, wo diese jeweils von der Qualität her im Vergleich zum TGMC liegen.

Zitat von Didée

Ach, falls es jemand interessiert: Vom TGMC gibt's inzwischen die Version Beta-2.

Hab mich jetzt an die Tempgauss_MCbeta2u herangewagt und mit NNEDI3, qual=2, nns=3, nsize=3 getestet. Abgesehen davon, daß man mit diesen rechnerintensiven Einstellungen keine Massenkonvertierungen vornehmen kann, ist Folgendes aufgefallen. Die lossless-Option führte bei den Werten 1-3 immer kurz nach Konvertierungsbeginn zum Absturz, habe sie deaktiviert. Die Ergebnisse sind wirklich Spitze!