Avisynth MT, nicht immer sinnig,...

    Hab mich die letzten paar Stunden mal genauer damit beschäftigt welche Funktionen/Skripte den überhaupt von Avisynt MT profitieren.
    Habe also mal wie wild Funktionen/Skripte mit unterschiedlichen SetMTMode-Aufrufen gecheckt und musste feststellen, das man viele F/S am besten doch ohne MT benutzen sollte.
    Hier hab ich mal aufgelistet von den F/S die ich getestet habe, welche davon:
    a. überhaupt von MT profitieren
    b. wenn sie profitieren, welcher Mode am flottesten (ohne kaputtes Bild) läuft
    c. wenn sie nicht profitieren, welchen Mode man nehmen sollte, wenn sie in einem MT Skript sind
    d. welche Filter so langsam sind, oder durch MT so langsam werden, dass man MT lieber gleich direkt deaktivieren sollte.

    Würde mich über Meinungsäußerungen und Erweiterungen freuen, aber wenn nicht dann nicht.

    Cu Selur

    Irgendwas scheint mir da komisch. Da sind so einige Sachen dabei, die definitiv von MT profitieren sollten, aber in der Liste steht "no" drin. :huh:

    Erzähl mal was über das Setup - Welche Version von Avisynth-MT, Art des Videomaterials, welcher Sourcefilter zum Laden, vollständiges Rahmenscript.


    edit:
    Also, z.B. FineSharp() wird bei mir schon mal mehr als doppelt so schnell, mit MTmode(2,4) : 63 --> 134 fps, oder Deblock_qed: 13 --> 36 fps, ....

    2 Mal editiert, zuletzt von Didée (27. März 2013 um 23:32)

    Quelle was ein 720p mkv file, für FineSharp() sah das Basisskript wie folgt aus:


    DGSource alleine schafft so ca. 290 fps beim Dekodieren.

    FineSharp ohne MT kommt so auf ca. 46
    bei SetMTMode(6,0) vor DGSource und SetMTMode(2) komme ich hier so auf ca. 3 fps
    bei SetMTMode(6,2) vor DGSource und SetMTMode(2) wird es noch langsamer,...
    bei SetMTMode(4,2) vor DGSource und SetMTMode(2) ist auch langsamer
    vermute das Problem bei FineSharp ist, dass es halt nicht dafür gedacht ist auf HD Material zu laufen,... ;)

    Geschwindigkeit hab ich mit AVSMeter getestet,...

    Zitat von Selur

    vermute das Problem bei FineSharp ist, dass es halt nicht dafür gedacht ist auf HD Material zu laufen

    Nee, ne-neee. Das Problem ist einzig+allein DGSource. Das arbeitet sehr oft gar nicht gut mit MT-Scripten zusammen.

    Probier mal irgendwas mit ffvideosource, oder Mpeg2source(), oder Avisource. Das Gesamtbild in Deiner Tabelle wird sich grundlegend ändern. :)


    edit
    Ooooooder ... probier mal, direkt nach dgsource ein RequestLinear(rlim=50,clim=50) als Puffer zu setzen.
    DGsource mag es einfach nicht, wenn es Anforderungen von mehreren Downstream-Threads erfüllen muss ...

    Einmal editiert, zuletzt von Didée (28. März 2013 um 00:20)

    Faustregel: GPU-beschleunigte Plugins immer nur einmal laufen lassen (DGDecNV, FFT3DGPU, NLMeansCL...).

    P.S.: Könnte bitte der eine oder andere mal nachhaken, weil ihn solche Grundsatzfragen auch interessieren? Wenigstens einer (z.B. SEt) muss das doch genauer wissen, um es auch erklären zu können... Danke.

    Zitat

    Faustregel: GPU-beschleunigte Plugins immer nur einmal laufen lassen


    mit mode 6 sollte es doch nur einmal laufen,...

    Zitat

    probier mal, direkt nach dgsource ein RequestLinear(rlim=50,clim=50) als Puffer zu setzen.


    werde ich testen -> hui, und so werden aus 3 -> 200fps => werde die Tabelle später noch mal überarbeiten :)

    Was macht RequestLinear eigentlich genauer? Stelle gerade fest, das einige Scripte auch wenn MT nicht genutzt wird flotter sind wenn RequestLinear verwendet wird,...
    (bei deaktiviertem MT, also keinerlei SetMtMode Aufrufe im Skript ohne RequestLinear, schafft FastLineDarkenMOD so 30 fps mit RequestLinear im Skript sind es dann 45fps; analoges passiert bei Nutzung von Hysteria)
    -> scheint als ob RequestLinear, sobald DGSource verwendet wird zumindest nie schadet, aber teilweise hilft und wenn DGSource mit MT verwendet zusätzlich enorm hilft.

    stimmt:

    Zitat

    RequestLinear makes sure that all requests for frames from the filter downstream are turned into linear requests for frames from the filter upstream of it. This can be useful when you want to use a filter that requests frames non-linearly in combination with a filter that requires linear requests.


    -> DGDecNV ist schon ein merkwürdiger Filter,.. :)

    Hab die Tabelle jetzt aktualisiert und jetzt sieht das ganze schon wesentlich besser aus. :)
    Nur TemporalDegrain mit TemporalDegrain(pel=2,blksize=8,ov=2,degrain=2,limit=255,SAD1=300,SAD2=300,HQ=1) ist in jedem MT mode bei mir langsamer als ohne MT, da es aber an sich schon so extem lahm ist, macht das auch nicht wirklich viel aus.

    Zitat

    Das ist nur in wenigen Szenarios erforderlich (piping, ffdshow).


    ich weiß, da ich in Hybrid aber fast immer pipe,.. :)

    Sieh' an, wie sich das Bild gewandelt hat.

    Betreffs "TemporalDegrain": Also, "eigentlich" profitiert das Ding auch von MT. Das Problem ist hier die extreme Komplexität, verursacht durch die Verkettetung von MVTools-Anwendungen. Die treibt u.a. den Speicherbedarf sehr stark in die Höhe, verursacht Probleme mit Avisynth's internem Frame-caching (Strategie welche Bildinstanzen gecached werden müssen usw.), ...
    Insbesondere bei HD geht das dann ganz schnell in die Hose mit dem MT. Bei 1080p sowieso, und bei 720p wirds auch schon sehr eng ... manchmal kann man über Setmemorymax noch einen Sweetspot finden, aber eigentlich ist 720p schon zu viel. (Außer, vielleicht, bei gecropptem 2.35 Cinemascope.)

    Allein der Umstand, dass etwas durch MT langsamer wird, ist ein deutlicher Hinweis, dass die Komplexitätsgrenze überschritten wurde. Kannst ja mal mit SD-Videos gegenprüfen - bin mir ziemlich sicher, dass da TemporalDegrain ebenfalls durch MT schneller wird.

    Schneller Test mit nem 720x576 TV-capture: ohne MT 5 fps, mit MT (4 Threads) sinds 9 fps.

    vob einer dvd genommen:
    ohne MT: 6,5fps
    mit MT - mode 2: 15,75
    werde später noch mal etwas mit setMemoryMax testen,..
    gerade mal mit SetMemoryMax(2048) beim 720p Sample getestet (vorher hatte ich mit 1024):
    mit MT - mode 2 mit setMemoryMax(768 MB): AVSMeter 1.46 liefert 1 fps, 1.47 liefert 7 fps (belegt 1.190 MB)
    mit MT - mode 2 mit setMemoryMax(1024 MB): AVSMeter 1.46 schmiert ab, 1.47 liefert 7 fps (belegt 1.453MB)
    mit MT - mode 2 mit setMemoryMax(2048 MB): AVSMeter 1.46 liefert 0.6, , 1.47 liefert 7 fps (belegt 2.500MB)
    ohne MT mit setMemoryMax(768 MB) liefert AVSMeter 1.47 immer noch die gewohnten 3fps
    -> scheint so als ob die alte AVSMeter Version Probleme mit speicherintensiven Skripten hatte. :)

    Zitat von Selur

    scheint so als ob die alte AVSMeter Version Probleme mit speicherintensiven Skripten hatte. :)


    Bei 1.46 hatte ich vergessen, die "LARGEADDRESSAWARE" Linker-Option zu setzen. Ich vermute , dass du die Tests auf 64-Bit Windows gemacht hast?

    Ja, hab ich, aber sollte LARGEADDRESSAWARE nicht erst bei 2GB Speicherverbrauch greifen? Irgendwie ist mir nicht klar warum es schon bei 1.453MB abgeschmiert ist und warum die Variante die 1.190MB belegt so langsam lief.
    Ist aber nicht so tragisch geht jetzt ja. :)

    Zitat von Selur

    Ja, hab ich, aber sollte LARGEADDRESSAWARE nicht erst bei 2GB Speicherverbrauch greifen? Irgendwie ist mir nicht klar warum es schon bei 1.453MB abgeschmiert ist und warum die Variante die 1.190MB belegt so langsam lief.


    Keine Ahnung warum...
    Das ganze System ist sehr komplex (wie Didée oben bereits bemerkt hat).

    Ich bin nicht sicher ob es genau zu dem passt, was du untersuchst. Der Vorteil von MT beim QTGMC Deinterlacer ist enorm. Da recht aufwendig (aber entsprechend gut) deinterlaced wird, ist schnell das Limit eines einzelnen Threads erreicht. Bei meinem Quadcore liegt der Vorteil bei einem Faktor von knapp über 3.
    Ich vermute, dass man bei yadif keinen großen Unterschied bemerken wird.

    Grundsätzlich schon richtig: Es kommt auf das Verhältnis des Rechenaufwandes zwischen Filterung und Encodierung an. Wenn das Filtern im Vergleich zur Encodierung aufwändig ist, dann beschleunigt Multithreading beim Filtern die gesamte Berechnung wahrscheinlich deutlicher. Ist dagegen die Filterung allein schon sehr schnell, hat noch ein bisschen mehr Beschleunigung verhältnismäßig weniger Einfluss.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden