TGMC-Beta2 und AviSynth-MT 2.58 – Finetuning

Schade nur, dass der Typ seit beinahe 20 Jahren aus der "Programmiererszene" ausgestiegen ist. Nächstes Jahr ist Jubiläum.

Überrascht mich etwas, dass QTGMC weniger gute Qualität produzieren sollte als TGMC. Screenshot oder kurzes Sample-Video wären durchaus interessant.

Auslastung ... kann ich irgendwie nicht so ganz nachvollziehen. Habe mal Dein Script auf meinen 4C8T-CPU angepasst (d.h. alles was die Thread-Anzahl betrifft einfach verdoppelt), und dann mit identischen Parametern TGMC und QTGMC anhand eines SD-Videos verglichen:

setmtmode(5,8)
mpeg2source("G:\Video\LordOfDance\vts_01.d2v")
setmtmode(2)
TempGaussMC_beta3(2,1,3,0,0,0,Edimode="NNEDI3",nthreads=8,truemotion=true,sharpness=1.75,Sbb=2,SLrad=1,SVthin=0.75,Sovs=2) 
#QTGMC(2,1,3,0,0,0,Edimode="NNEDI3",edithreads=8,truemotion=true,sharpness=1.75,Sbb=2,SLrad=1,SVthin=0.75,Sovs=2) 
return(last)

TGMC: Auslastung 70%~80% (szenenabhängig), Speed=~25.6 fps
QTGMC: Auslastung 70%~80% (szenenabhängig), Speed=~26.0 fps

Für mich verhalten sich die beiden also ziemlich identisch ... und mir fehlt die zündende Idee, was Dir da jetzt raten sollte.

Ah, den Clip hab' ich ja schon ... bei "Cupture" hat in den grauen Zellen ein Glöckchen geläutet.

return(last) macht eben das: den aktuell in der Variablen "last" stehenden Inhalt an die übergeordnete Anwendung zurückliefern. Gebräuchlich vor allem, wenn man innerhalb eines längeren Scriptes 'rausspringen und etwas bestimmtes zurückliefern will. Am Script-Ende braucht man's nicht unbedingt ... es heißt ja: "Avisynth nimmt am Ende des Scriptes automatisch 'return(last)', wenn es nicht ausdrücklich angegeben ist." (Oder so ähnlich). Allerdings gibt es einfache Beispiele, wo dies nicht wie gewünscht funktioniert ("Avisynth error: the Script's return was not a video clip").
Ich schreib's halt einfach (fast) immer am Ende hin - tut nicht weh, kann aber Probleme vermeiden.

Was mir inzwischen beim TGMC<>QTGMC-Vergleich aufgefallen ist:

- QTGMC ist anscheinend immer etwas "schärfer". Warum, das muss noch erforscht werden. Betrifft natürlich sowohl "Detail", als auch "Rauschen" und "Quell-Artefakte". Zuerst aufgefallen ist mir's bei den Artefakten, nicht beim Bilddetail.

- beim QTGMC sollte man "precise=true" verwenden. Die entsprechende Code-Zeile war in früheren TGMC-Versionen nicht vorhanden, die aktuelle verwendet es *immer*. (Es geht darum, dass beim Schärfen der kleinstmögliche Unterschied von +/-1 nicht aussagekräftig ist, ein solcher Unterschied kann sowohl "korrekt" als auch "falsch" sein. Deswegen ist es besser, beim Schärfungsvorgang den berechneten Unterschied von vornherein um "1" zu verringern, damit dieser mögliche Fehler gar nicht erst auftritt.) (Man könnte dies auch als "die Heisenberg'sche Unschärfebeziehung im 8-bit-Farbraum" bezeichnen.)
Jedenfalls - QTGMC verwendet "precise=true" nur für die zwei langsamsten Presets. Die Option ist aber Geschwindigkeits-technisch kaum relevant, an der Speed ändert sich da praktisch gar nichts. Deswegen: solange die Presets nicht geändert werden, sollte man beim QTGMC immer fleißig "precise=true" manuell angeben.

Re: Edit

Ja, das kann schon sein. Mich überrascht eher, dass die "vielen" Edi-Threads oftmals *trotzdem* gut funktionieren, wenn man QTGMC mit SetMTmode verwendet. Die Grundidee ist ja, dass z.B. 4 Threads laufen, wobei jeder Thread "seinen eigenen Frame" bearbeitet. Wenn nun NNEDI noch mit vielen Threads läuft, dann heißt das ja, dass der EINE MT-Thread, der gerade einen Frame bearbeitet, wiederum mehrere Threads für NNEDI abspalten muss.

Beispiel: Wenn ich angebe:

SetMTmode(2,8)
TGMC(....,nthreads=8)

Dann sieht das zunächst "okay" aus: meine CPU hat "8 Threads", also immer schön 8 Threads für alles angeben.

Tatsächlich ist es aber so, dass in 8 MT-Threads jeweils ein NNEDI läuft, und jedes NNEDI verwendet 8 interne Threads. Das heißt, dass NNEDI insgesamt 64 Threads initiiert. (!!!)

Warum das trotzdem mit ordentlicher Geschwindigkeit läuft, ist für mich eher überraschend als "logisch" ...

Zitat von Propaganda

Bei Qualität bevorzuge ich aber lieber Deine TGMC Version(8-9,5fps). QTGMC ist unnötig zu scharf eingestellt.

Wie gesagt, da müsste man nachforschen. Glaube nicht, dass QTGMC wirklich schärfer "eingestellt" ist ... sondern eher, dass sich da ein Bug/Feature beim Herumscripten eingeschlichen hat.

Zitat

"precise=true" hatte ich auch mal eingefügt zieht aber die Kiste gleich in den Keller. 5-6fps bei schnellen Bewegungen.

Das kann ich mir beim besten Willen nicht vorstellen. "precise=true" wirkt sich in QTGMC nur an zwei Stellen aus:

(1) rgBlur       = (Precise) ? 11 : 12  # Version of RemoveGrain blur to use


(2) vresharp  = (Precise && SMode == 2) ? vresharp1.mt_lutxy( lossed1, "x y < x 1 + x y > x 1 - x ? ?", U=3,V=3 ) : vresharp1 # Precise mode: reduce tiny overshoot

(1) ist trivial, statt einem "500fps Filter" wird ein "450fps Filter" verwendet. Macht keinen Unterschied.

(2) ist nicht trivial, aber dieses einzelne lutxy macht im Gesamtbild vielleicht 0.1 fps Unterschied aus, wenn überhaupt. Exakt der gleiche Filter ist in TGMC "fest verdrahtet". Wenn's also daran liegen würde, dann müsste TGMC auch das gleiche Verhalten zeigen.

Insbesondere sind diese beiden Unterschiede absolut unabhängig von Bild- oder Bewegungskomplexität. Es kann gar nicht sein, dass precise=true einen Unterschied bei großer Bewegungskomplexität verursacht.

Es gab da mal einen Jungen, der in genau dem Moment gegen einen Laternenmast getreten hat, als ein stadtweiter Stromausfall eingetreten ist. Der Junge dachte natürlich, er hätte den Stromausfall verursacht ...

Bei solchen Geschwindigkeitsvergleichen unter Vdub auf keinen Fall das "Refresh" bzw. "Reload Source" Feature verwenden! Es findet hierbei kein sauberer Memory-Flush statt, und die Ergebnisse können verbogen sein. Bei solchen Vergleichen Vdub am besten immer komplett beenden, Windows einige Sekunden Zeit zur Speicherorganisation geben, dann Vdub wieder starten und das Script neu laden. Etwas umständlich, ja. Aber nach einem "Refresh" des Scriptes kann alles mögliche passieren, die Ergebnisse sind nicht zuverlässig. Insbesondere bei solch "hochkomplexen" Scripten wie Q/TGMC, und insbesondere bei Verwendung von SetMTmode. Und erst recht, wenn beides zusammen kommt.

Zitat

Aber eine gute Sache hat das Einfügen von "return(last) gebracht.Seitdem habe ich keine Bildfehler mehr :daumen::daumen::daumen:

Könnte mit dem Automatismus "Inherentes "Distributor() in VfW" zusammenhängen.
(Obwohl: dieser Bildfehler sieht eigentlich eher nach "MT(..) als nach SetMTmode(..) aus ...)

Zitat von Propaganda

Arbeit ruft!

Mögliche Hilfe: http://tinyurl.com/6bjsb4l

Jo, wer suchet, der findet ...

Kurz: in TGMC ist "sharpness" ein Absolutwert (wenn er angegeben wird). In QTGMC ist's ein Relativwert.

Beim TGMC ist es so:
- es gibt einen Automatismus, der einen Schärfewert ermittelt (in Abhängigkeit von anderen Parametern).
- dieser Auto-Wert wird nur verwendet, wenn der Benutzer *keinen* Wert für "sharpness" angibt.
- wenn der benutzer "sharpness" ausdrücklich angibt, dann wird der Automatismus nicht verwendet. Stattdessen wird der Schärfewert des Benutzers verwendet.

QTGMC macht es anders:
- es gibt einen Automatismus, der einen Schärfewert ermittelt (in Abhängigkeit von anderen Parametern)
- dieser Auto-Wert wird IMMER verwendet
- wenn der Benutzer ausdrücklich einen Wert für "sharpness" angibt, dann wird dieserWert als Multiplikator für den Auto-Wert verwendet.
- wird nichts angegeben, ist der Multiplikator 1.0

QTGMC macht da also nichts falsch. Im Gegentum, dessen Methode ist sogar besser.

... Nur eben, dass aufgrund dieser unterschiedlichen Handhabung die Schärfe-Were nicht 1:1 zwischen TGMC und QTGMC ausgetauscht werden können ...

konkretes Beispiel:

TGMC: "sharpness=1.75" ---> effektiver interner SchärfeMultiplikator = 1.75

QTGMC: "sharpness=1.75" --> effektiver interner SchärfeMultiplikator = 2.88 (wenn tr1=1, tr2=3)

Das ist ein merklicher Unterschied. Um mit Deinen aktuellen Einstellungen den gleichen Schärfewert zu erzielen wie TGMC(sharpness=1.75), wäre QTGMC(sharpness=1.0606) wohl richtig ....

Klar wie Kloßbrühe. BRRRRR!!!.

MPEG2Source im Multi-Threading-Bereich ... das ist gewagt. Ich glaube nicht, dass Donalds Plugins reentrant programmiert wurden.

Allerdings habe ich keine Ahnung von den Auswirkungen der MT-Modi. Vielleicht ist die 5 genau dafür gedacht?!

SetMTMode(2) hat einen bestimmten Zweck und bestimmte Nebenbedingungen.

SetMTMode(5) hat einen bestimmten Zweck und bestimmte Nebenbedingungen.

Kann sein, dass eines der beiden mit MPEG2Source() funktioniert. Oder auch nicht. Da fehlt mir die Erfahrung.

Damit bestimmte Funktionen multi-threaded funktionieren, müssen sie geeignet programmiert sein (re-entrant = ausschließlich lokale Variablen verwendend), damit nicht die eine Kopie der Funktion die Variablen der anderen Kopie durcheinander bringt. Donald Graft hat bei DGMPGDec auf so etwas nicht geachtet. Deshalb sind die für SetMTMode(2) ganz bestimmt nicht geeignet. Ob sie mit SetMTMode(5) funktionieren, weiß ich nicht.

Rein theoretisch ist das Script völlig richtig: passt alles.

(Durch MTmode=5,8 wird festgelegt dass im Script generell 8 Threads genutzt werden, jedoch wird mit der "5" zunächst nur 1 einzelner Thread aktiv geschaltet. Die 8 Threads werden erst nach mode=2 aktiviert. Somit ist mpeg2source "gesichert".)

Praxis ist aber, dass die ganze MT-Geschichte nicht endgültig stabil ist. Und da hilft einem die schöne Theorie auch nicht weiter.

Ist ja schön dass das Ganze mit DSS nicht zusammenbricht. Aber: wenn Frame-Sprünge auftreten, dann ist das ein Zeichen dafür, dass Avisynth-intern irgendwas mächtig daneben geht. Weil, das ist ja ein rein lineares Script, und deswegen sollten eigentlich keine Out-of-Order Framerequests an den Sourcefilter gestellt werden. Soll heißen: Kaputt isses trotzdem, und dass kein Crash auftritt ist nur ein zufälliger Nebeneffekt ...

Probier' das mal so:

SetMTmode(5,[COLOR='darkred'][B]6[/B][/COLOR]) # weniger ist manchmal mehr


LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\DGDecode.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\nnedi3.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\mt_masktools-25.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\mvtools2.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\RemoveGrainSSE3.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\RepairSSE2.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\VerticalCleanerSSE2.dll")


Import("C:\Programme\AviSynth 2.5\plugins\TGMC Paket\TempGaussMC_beta3.avsi")




Mpeg2Source("E:\Camel Safari Video\DVD Dateien\Camel Safari.d2v")
[COLOR='darkred'][B]Changefps(last,last,true)[/B][/COLOR]


SetMTmode(2)


TempGaussMC_beta3(2,2,3,0,0,0,Edimode="NNEDI3",nthreads=[COLOR='darkred'][B]2[/B][/COLOR],truemotion=true,sharpness=1.75,Sbb=2,SLrad=2,SVthin=0.75,Sovs=2)


return(last)

Insbesondere die Reduzierung der "nthreads". Weil, ursprünglich ist NNEDI3 in 8 Threadss gelaufen (SetMTmode), und jeder dieser 8 NNEDI3's hat jeweils 8 eigene Threads abgepaltet (nthreads). In dem Script waren also 8x8 = 64 NNEDI3-Threads (!) aktiv. Klingt viel? IST viel! Die Erfahrung hat gezeigt: weniger ist manchmal mehr...

Stabilitäts-technisch hab' ich bei Q/TGMC mit 6 MTmode-Threads mehr Freude als mit 8 Threads

Die ChangeFPS-Zeile puffert einige Frames (read-ahead). Ist desöfteren hilfreich, und schaden tut's auf keinen Fall.

Ach, und setz' vielleicht auch noch SetMemoryMax(800) oder so. Der Default geht niemals höher als 512, das könnte in diesem Szenario etwas knapp sein.

Encodierst Du das direkt mit x264? Wenn ja, dann winkt natürlich auch noch die 2GB-Barriere. Mal mit dem Taskmanager nachverfolgen: Wenn Avisynth (bzw. x264 als Host-Prozess) die 1.7 GB überschreitet, dann macht's vermutlich bald PENG! ....

Falls Avisynth 2.5.8.5.MT genutzt wird: Die 2.6.MT von SetH (die von 2009) ist deutlich stabiler im Multithreading ...

-Vit- hat auch ein paar Plugins neu kompiliert. Zum Versuch freigegeben hat er die MaskTools.dll ... der Beschreibung nach sind da ein paar "Tricks" (bezüglich Frame-Requests) drin bei denen mir ganz seltsam in der Magengrube wird. Sowas wie "gerissenen Wasserschlauch ganz dick mit Klopapier umwickeln". Angeblich sei das stabiler, probiert hab' ich's noch nicht ....