Avisynth MT, nicht immer sinnig,...

Zitat von Selur

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

Ich habe mal mit SD-Material getestet.
- ohne MT wird nur eine der 4 CPUs ausgelastet
- mit MT ist die Auslastung zwar besser, deshalb wird's auch schneller, die fps pro CPU-Auslastung (= Effizienz) sinken allerdings etwas
- mit Requestlinear wird's schlimmer

ohne MT
41fps / 25% CPU / 1 Thread / 209MB physical / 225MB virtual / 1,64 fps/cpu

MT ohne RequestLinear:
106fps / 73% CPU / 5 Threads / 313MB physical / 330MB virtual / 1,45 fps/cpu

MT mit RequestLinear:
16fps / 33% CPU / 5 Threads / 508MB physical / 525MB virtual / 0,48 fps/cpu

SetMemoryMax(512)
SetMTmode(3,0)
LoadPlugin("C:\PROGRA~1\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\AGC.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\DeGrainMedian.dll")
mpeg2source("C:\Rekorder\aaa\aaa.d2v", cpu=4)
requestlinear()
SetMTmode(2)
trim(407,34832)+trim(46866,75650)+trim(87084,116945)+trim(128461,155874)+trim(166280,187498)
crop(2,72,716,432)
merge(last,last.hdragc(),0.25)
DeGrainMedian(limitY=5,limitUV=7,mode=2)
BicubicResize(704,432,0,0.5)
RETURN( LAST )

Gruß

akapuma

Auch mit dem vergrößerten Pufferbereich wie im zitierten Vorschlag?

Ich muss aber zugeben, dass der Zweck der Parameter nicht wirklich trivial ist.

Ansonsten gibt es in AviSynth MT 2.60a4 auch noch eine Funktion Preroll(). Die ist aber eigentlich etwas simpler als RequestLinear(), glaub ich...

Zitat von LigH

Auch mit dem vergrößerten Pufferbereich wie im zitierten Vorschlag?

Nein.

Ich habe jetzt mal "requestlinear(rlim=50,clim=50)" probiert. Leider stürzt das AVSMeter dann mit einem Runtime-Error ab. Es scheint aber kein Avisynth-Fehler zu sein, denn der MPC spielt die AVS-Datei ab. Da sie aber etwas hakelig läuft, denke ich, daß die zusätzlichen Parameter auch nichts bringen.

Gruß

akapuma

Irgendwie ist dein Test nicht gerade so wie geplant...

Du setzt Mode 3 vor LoadPlugin, aber Mode 2 schon vor MPEG2Source. Da kannst du auch gleich mit Mode 2 anfangen, denn was tun die LoadPlugin-Befehle schon nach dem Start des Skriptes? Nichts mehr. Aber gerade Source-Plugins sollten durch Mode 3(+) ja vor Parallelausführung geschützt werden; wenn die Multithreading unterstützen, sollen die das schön selber in sich machen, und wenn nicht, dann sind sie meist auch ungeeignet: Thread-safe implementation, reentrance, ...

Dann führst du nach MPEG2Source.RequestLinear überhaupt keine Filter mehr aus. Also gibt es auch überhaupt keine gleichzeitigen Frame-Anfragen von unterschiedlich positionierten Plugins in mehreren Threads, welche durch RequestLinear linearisiert an MPEG2Source weitergeleitet werden. Filter mit größerem temporalem Fenster wären hier interessanter gewesen. Ganz zu schweigen von Trims...

Praxisrelevant ist dieser Test nicht gewesen.

Zitat von Selur

Und wie sieht es ohne das DeGrainMedian aus? (nur um zu wissen ob es eventuell an der Kombination liegt)

Nein, das ist es nicht.

Gruß

akapuma

Zitat von Selur

Code

SetMemoryMax(768)SetMTMode(6,0) # change MT modeLoadPlugin("G:\Hybrid\avisynthPlugins\DGDecodeNV.dll")LoadPlugin("G:\Hybrid\avisynthPlugins\TIVTC.dll")# loading sourceDGSource(dgi="H:\Temp\46570770deb1536f480475f7d593219aa1afd74c_41.dgi",fieldop=0)RequestLinear(rlim=50,clim=50)return last

(sehr verwundert warum Acitve MT Mode 5 ist)

Gar nicht verwunderlich (von avisynth.cpp):

void ScriptEnvironment::SetMTMode(int mode, int threads, bool temporary) {
  if (temporary && mt_mode==-1)
    return;
[B][COLOR='#0000FF']  if (mode == 6) {
    mode = 5;[/COLOR][/B]
    InterlockedIncrement(&Mode5Gate::suspendedthreads);
  }
  if (threads > 0 && mt_mode == -1)
    nthreads = threads;
  if (mt_mode != 0 && mode >= 1 && mode <= 5) {
	if (temporary && temp_mt_mode == -5)
		temp_mt_mode = mt_mode;
    mt_mode = mode;
  }
  if (mt_mode == -1 && mode == 0)
    mt_mode = 0;
  if (mode == -5 && temp_mt_mode != -5) {// restore permanent mtmode
	  mt_mode = temp_mt_mode;
	  temp_mt_mode = -5;
  }
}

:cool:

Sehr interessant dürften Ergebnisse zu diesem Frame interpolarisations Filter sein: http://forum.doom9.org/showthread.php?t=160226
So genau kann ich es nicht sagen, aber ich konnte keinen großen Geschwindigkeitsunterschied zum encoden ohne ihn feststellen. Ich persönlich würde aber einen erwarten. Vielleicht verrechne ich mich auch einfach, denn die fps blieben gleich, aber die Anzahl der zu encodenden Frames hat sich ja verdoppelt.
(Nebenbei bemerkt, bei Filmen von 24p auf 48p zu gehen wirkt Wunden und funktioniert in jeder Situation, was bei Fernseher die das in Echtzeit machen müssen nicht der Fall ist.)

Zitat von Rattenjäger

(Nebenbei bemerkt, bei Filmen von 24p auf 48p zu gehen wirkt Wunden und funktioniert in jeder Situation, was bei Fernseher die das in Echtzeit machen müssen nicht der Fall ist.)

Nebenbei vermutet: Du hast nicht zufällig einen Fernseher von LG, nein? Wenn Dir die Echtzeitberechnung von TVs nicht gefällt, dann hast Du wahrscheinlich keinen Samsung oder Sony?

Ist Multithreading überhaupt sinnvoll? Hier sind mal ein paar Rechenbeispiele mit ausgedachten Zahlen am Beispiel eines Quad-Core-Prozessors:

1. Skripttest ohne MT:

Nur einer der 4 Prozessorkerne wird benutzt, und der zu 100%. Daraus resultiert eine Gesamt-Prozessorlast von 25%. Das Skript schafft 50fps.

2. Skripttest mit MT:

Alle 4 Prozessorkerne werden zu 100% benutzt. Daraus resultiert eine Gesamt-Prozessorlast von 100%. Das Skript schafft jetzt 50fps x 4 x 0,8 = 160fps.
Der Faktor 0,8 ist ausgedacht und soll berücksichtigen, daß mit MT mehr herumgerechnet werden muß als ohne MT.
Jetzt freut man sich, weil 160fps mehr als 3x so schnell ist wie 50fps.

3. reales Encoden ohne MT, angenommen, der Encoder benötigt 7 x soviel Rechenleistung wie Avisynth

Ein Kern wird zu 50% von Avisynth benutzt. Die andere Hälfte des Kerns, sowie die 3 anderen Kerne, werden vom Encoder (z.B. x264), der prima multithreadingfähig ist, vollständig aufgefüllt.
Im Beispiel kommt man dann auf 25fps bei 100% Prozessorlast.

4. reales Encoden mit MT, angenommen, der Encoder benötigt 7 x soviel Rechenleistung wie Avisynth

Es werden 4 Kerne von Avisynth benutzt. Diese werden dann zu rund 4 x 15% von Anisynth benutzt, und zu rund 4 x 85% vom Encoder.
Insgesamt sind das dann 100% Prozessorlast. Die fps sinken dann auf 24,2fps, weil ja mit Multithreading mehr gerechnet werden muß als ohne. Wurde man das nicht berücksichtigen, käme man auf 25fps.
Gegenüber Beispiel 3 bringt das nichts.

5. reales Encoden ohne MT, angenommen, der Encoder benötigt 2 x soviel Rechenleistung wie Avisynth

Avisynth belegt einen Kern zu 100%. Der Encoder belegt die 3 anderen Kerne. Da Avisynth das Ganze ausbremst, werden hie Kerne nur zu 67% belegt. Insgesamt liegt die Prozessorlast bei nur 75%.

6. reales Encoden mit MT, angenommen, der Encoder benötigt 2 x soviel Rechenleistung wie Avisynth

Avisynth belegt alle 4 Kerne zu 38,5%. Der Encoder belegt den Rest der 4 Kerne zu je 61,5%. Jetzt liegt die Prozessorlast bei 100%.
Gegenüber Beispiel 5 steigt die Framerate um 23%.

Fazit:

Avisynth-MT bringt beim realen Encoden nur dann etwas, wenn der Rechenanteil von Avisynth größer ist als 100%/Anzahl Kerne. Also 50% beim Dual-Core, oder 25% beim Quad-Core.

Sehe ich das falsch?

Gruß

akapuma

Ich will jetzt nicht die exakten Zahlen beurteilen; aber es ist sicher richtig, dass AviSynth-MT umso nützlicher ist, je höher der Rechenaufwand von AviSynth im Vergleich zum Encoder ist. In dem Fall wartet dann ja auch der Encoder darauf, dass AviSynth nun endlich mal wieder ein Frame liefert...

Wie beim Ausgießen einer Flasche: Damit es schneller fließt, muss der Hals breiter werden, nicht der Bauch.