Fehler in der Framereihenfolge durch MT?

Ja, die meisten Sourcefilter mögen kein MT. Mit mode=3 kommt man bei AviSource meist durch, aber MPEG2Source() läuft nur mit mode=5 oder ohne MT ordentlich, wie ich selber festgestellt habe.
Also einfach das erste SetMTmode ändern in 5,8 (wobei ich mit 8 Threads auch vorsichtig wäre, denn ich meine im englischen doom9 gelesen zu haben, dass die Faustregel besagt, es auf die Hälfte der vorhandenen Kerne zu setzen – jedenfalls frisst es viel RAM, was zu Instabilität führen kann).

Sonderbarerweise hat SEt nun für AviSynth MT ab Version 2.60 alpha 3 oder 4 dokumentiert, dass man Mode 5 nicht mehr nutzen solle und Mode 3 genüge; wenn das im Fall von MPEG2Source nicht stimmt, ist das ein weiterer Grund, noch mal nachzuhaken, denn ich warte immer noch vergeblich darauf, dass mal die Details der Modi über 2 erklärt werden, und so etwas kann anscheinend nur SEt...

Die Beschränkung der Kerne auf maximal 4 würde ich auch empfehlen, denn es gibt komplexe Filter, die in AviSynth sehr viel RAM benötigen, was sich pro Parallelisierung erhöht; und auch der nachfolgende Encoder, sicherlich x264, wird RAM und Rechenleistung brauchen.

Groucho2004 hat mich auf eine Erklärung von IanB verlinkt. Daraus geht hervor: Modi 3-6 unterscheiden sich nur in Details. Man sollte also im Grunde schon bei Modus 3 bleiben; aber es gibt Möglichkeiten, den Quellfilter zu entlasten, dass er nicht andauernd verschiedene Threads bedienen muss, die sich um die aktuelle Position der Decodierung streiten. Dies wird erreicht durch einen "Pufferfilter" zwischen dem Quellfilter und dem hauptsächlich multithreaded ausgeführten Filter, welcher ein paar Frames in der Nähe der aktuellen Position zwischenspeichert und neue Frames schön brav in der aufsteigenden Reihenfolge vom Quellfilter abfragt.

Eine Variante ist der Filter RequestLinear() aus dem Plugin TIVTC von tritical. Der lässt sich auch schön detailliert konfigurieren, wie viele Frames davor und danach zur Pufferung bzw. einem schnellen oder kompletten Nachladen herangezogen werden sollen.

In AviSynth 2.60 alpha 4 wurde außerdem der Filter Preroll() hinzugefügt, der mir allerdings nicht ganz so ausgefeilt scheint.

Mein Vorschlag wäre also:

SetMemoryMax(1400)
[COLOR='#A9A9A9']LoadPlugin("DGDecode.dll")
LoadPlugin("TIVTC.dll")[/COLOR]
SetMTMode(3, [COLOR='#0000CD'][B]4[/B][/COLOR])


# SOURCE
MPEG2Source("source.d2v", cpu=4)
AssumeTFF()


# calculate PAR before cropping: PAR = DAR / SAR
PAR = 4.0/3.0 * Float(height) / Float(width)


[COLOR='#0000CD'][B]RequestLinear()[/B][/COLOR]
SetMTMode(2)


# DEINTERLACING
QTGMC(Preset="Slower", EdiThreads=1)


# CROPPING
crop(6, 2, -6, -2)


# calculate new DAR (SAR changed due to cropping): DAR = SAR * PAR
DAR = Float(width) * PAR / Float(height)


# set final DAR for MeGUI
global MeGUI_darx = Round(1000 * DAR)
global MeGUI_dary = 1000


return last

x264 sollte eigentlich immer nur linear Frames anfordern, das nicht lineare anfordern geschieht i.d.R. durch Filter,...

Zitat

32bit AviSynth kann unter 64bit nur maximal 4GB nutzen, oder?

benutze i.d.R. 768MB und hier und da 1024MB, mehr macht meiner Ansicht nach i.d.R. keinen Sinn, da es sich hier nur um den lokalen Speicher von Avisynth für Variablen handelt, der Speicher den eventuelle Filter verbrauchen ist da nicht drinne,..
sprich wenn Du Avisynth 1500MB zu ordnest von den 3GB die es unter 64bit zur Verfügung hat (LARGE ADDRESS SIZE), dann sind nur noch 1500MB für die anderen Filter da.
-> Der tatsächliche Speicherverbrauch ist auf <= 3GB eingeschränkt und wird vor allem durch die verwendeten Filter bestimmt.

Cu Selur

Wie mir erklärt wurde, sind es tatsächlich volle 4 GB, wenn ein 32-bit-Prozess Large-Address-Aware unter einem 64-bit-System läuft. Dann sind die Treiber-Speicherfenster und das Betriebssystem ja nicht in diesem Prozess-Speicher reserviert. Aber davon unabhängig: Es lohnt sich sicher, die Grenze nach unten auszutesten; es wird sicher gute Gründe geben, dass AviSynth selbst einen relativ konservativen Standard vorgibt.