TGMC CPU nicht voll ausgelastet

Tja, der Geist in der Maschine ...

Schon mal die Speicherauslastung gecheckt, wenn der Effekt auftritt?
Encoding eines einzelnen Files, oder Batch-Encoding?
Sitzt VirtualDub mit im Boot?
Falls x264: welcher Preset, bzw. welcher Wert für MBTree Lookahead?

Ja, RC-Lookahead. Also, ich tippe mal schwer auf ein Speicherproblem. TGMC nimmt sich ja ganz ordentlich, und x264 auch. Und gerade der LookAhead kann bei komplexen Scripten schon mal zum Stolperstein werden. Bei lookahead=60 müssen ja (mindestens) 60 Output-Frames von Avisynth - also von TGMC - ständig im Speicher gehalten werden, während immer neue Frames berechnet werden.

Was ist denn das Quellmaterial? SD 480i/576i, oder HD 1080i?

Tja, weiß auch nicht ... ich kenn' das Phänomen von Versuchen, 1080i->TGMC->x264 in einem Durchgang zu encoden. Mit 576i hatte ich das noch nicht...

Tippe trotzdem auf ein Speicherproblem. Ist im Script ein SetMemoryMax() angegeben? Wenn ja, welcher Wert? Wird Avisynth-Multithreading verwendet? Ist die RAM-Ausstattung des Rechners 2GB, oder ist's mehr? Betriebssystem XP, Win7, oder noch was anderes?

Das sollte Speichermäßig eigentlich reichen. Ich hatte gefragt, weil 2GB RAM unter Vista oder W7 etwas knapp sein könnten, um solch aufwändiges Encoding zu machen. Mit XP sollte das aber eigentlich reichen.

Versuch mal mit SetMemoryMax(700) am Script-Anfang. Avisynth-Version ist 2.5.8, hoffentlich? Die Vorgänger 2.5.6 und 2.5.7 hatten so ihre Problemchen mit starker Speicherauslastung - 2.5.8 verhält sich da stabiler.

Ansonsten - sorry, keine spezielle Idee. Wie gesagt, mit 1080i muss ich auch ordentlich Jonglieren, damit nichts ins Stolpern kommt ... aber mit normalen SD-Auflösungen klappt das immer problemlos.

"AviSynth-MultiThreading" (AviSynth-MT) ist eine spezielle Variante von AviSynth, die Video in mehreren Threads parallel auf mehreren Prozessoren/Kernen verarbeiten kann, wenn man's korrekt steuert.

Das "mt" vorn an mt_masktools hat nichts direkt mit Multi-Threading zu tun.

Und in der Praxis bedeutet das sowas wie:

720x576i -> TGMC(1,1,1,NNEDI2) -> x264 --slow

"Normales" Avisynth: 5.5 fps

"MT" Avisynth: 18.6 fps
(avs->6 threads / x264-> 10 threads) (auf i7-860, 4Kerne+HT)

Macht gute 4 Stunden für 1.5 Stunden Laufzeit des Eingangsmaterials. Dafür, dass die Geschwindigkeit von TGMC schon mit "Gletscherschmelze-Geschwindigkeit" verglichen wurde, dafür geht das doch eigentlich ganz in Ordnung.;)
(SD geht also ganz gut. Aber bei HD gibt's lange Gesichter, das tut immer noch richtig weh...)

Die 476MB Swap sind's wohl, die das ganze in den Keller ziehen. Vermutlich ist durch anderweite Rechnernutzung der Gesamtbedarf an RAM zu stark angestiegen, XP hat Teile von der ganzen Encoding-Geschichte ausgelagert, und jetzt will's nimmer so recht in den Hauptspeicher zurückkommen.

Auf die Qualität hat MemoryMax keinen Einfluss. Man kann damit nur die Cache-Größe von Avisynth etwas steuern. Bei 2GB Arbeitspeicher wird Avisynth per Default vrmtl. 384 bis 512 MB *) reservieren, je nachdem wie viel vom OS als "frei"/"verfügbar" gemeldet wird. Wenn man weiß dass man soviel gar nicht nicht braucht, dann setzt man weniger. Wenn man weiß dass man mehr braucht, dann setzt man mehr. Für Single-Threading reichen 512MB locker für den TGMC. Ebenfalls für MT(). Für SetMTmode() nehm' ich 1024 als Standard.

*) IanB hat mal gesagt, dass sich Avisynth 2.5.6 um den SetMemoryMax Wert überhaupt nicht schert - es neigt dazu, allen nur verfügbaren RAM mit seinem Cache vollzuknallen. Wie's be i2.5.7 war weiß ich nicht, die Version hab ich nie benutzt. Aber, von 2.5.7 auf 2.5.8 ist an dem Cache-Managment nochmal ordentlich 'rumgedoktert worden - im Endeffekt ist 2.5.8 ein klein wenig langsamer als 2.5.7, aber (vermutlich) auch stabiler.

Zum MultiThreading in Avisynth gibt's zwei Varianten: MT() und SetMTmode(). MT teilt jeden Frame in zwei oder mehrere Schnipsel ("Slices"), und jeder Slice wird von einem eigenen Thread bearbeitet. Im Gegensatz SetMTmode: hier bearbeitet jeder Thread einen vollständigen Frame.

Zum Schmökern: Link 1, und Link 2.

Vor/Nachteile MT():
+ braucht weniger Ressourcen
+ deswegen auch dort einsetzbar, wo SetMTmode zuviel Ressourcen brauchen würde
- technisch nachteilig: z.B. kann MVTools keine Bewegung über die Slice-Grenzen hinweg verarbeiten
- zur Vermeidung von Artefakten braucht man eine Überlappung der Slices. Um z.B. dem ^MVTools-Problem^ gegenzusteuern, braucht man viel Überlappung. Dadurch wächst die Gesamt-Bildfläche. Mehr Bildfläche -> langsamere Performance.
- man kann auch leicht "modulo-Probleme" bekommen (wenn z.B. die Höhe oder Breite eines Slices nicht mehr durch 4 oder 8 oder 16 teilbar ist - je nachdem was der Filter erfordert)

Vor/Nachteile SetMTmode():
+ technisch "reiner", weil die verschiedenen Nachteile des Slicings nicht auftreten
+ zumindest auf modernen i3/i5/i7: schneller als MT(). (Von älteren Dualcores habe ich schon das Gegenteil gehört.)
- braucht mehr Ressourcen
- funktioniert mit vielen, aber leider nicht mit allen Filtern

Bei mir wird kaum jemals etwas ausgelagert. (Aber das liegt an den 8 GB RAM & getweaktem Setup.);)

Avisynth 2.5.8.5 MT-Version: Siehe hier.

Zitat von Menedas

Mit MT habe ich so eine Art Horizontales Tearing. Das ist wohl das was Didée bereits vorausgesehen hat.

Jo. Gegenrezept hatte ich auch geschrieben, aber das hast Du vermutlich nicht probiert?

Zitat

zur Vermeidung von Artefakten braucht man eine Überlappung der Slices. Um z.B. dem ^MVTools-Problem^ gegenzusteuern, braucht man viel Überlappung.

Das wäre dann in etwa ...

MT(""" TempGaussMC_beta2(.....) """, threads=2, overlap=16)

Der "overlap" Wert macht's. Wenn die MVTools involviert sind, dann ist 1 x blocksize das empfohlene Minimum. 2 x blocksize ist besser / "sicherer" ... aber auch ein klein wenig langsamer.
Bei den meisten anderen Filtern reichen 2 oder 4 Pixel overlap - es kommt eben darauf an, eine wie große "Umgebung" der Filter für das aktuelle Pixel berücksichtigt. Die meisten Filter haben eine kleine Umgebung (Blur/Rauschfilter, etc.) oder sogar gar keine Umgebung (reine temporal-Filter). Aber die MVTools machen halt Bewegungssuche, und die kann sich theoretisch auch über den halben Bildschirm erstrecken.

Übrigens:

ColorBars()MT(""" Subtitle("Hello World") """,threads=8)

Zitat von Menedas

Ich habe jetzt auch mal SetMTMode in allen möglichen Modes ausprobiert auch SetMTMode(5,2), aber die CPU Last hängt immer irgendwo bei 80% rum. Nicht wie bei MT mit 98%. Damit dürfte es mir von der Geschwindigkeit her kaum etwas bringen

Wie war/ist das Script denn aufgebaut? Die generelle Rohform sollte so aussehen:

SetMTmode(5,<threads>)
LoadPlugin(...)
Import(...)
xyzSource(...)
SetMTmode(2)
FILTER()

Was mir jetzt erst aufgefallen ist: Mann-o-mann, Du hast aber auch alle Knöppe vom TGMC bis zum außersten Anschlag aufgedreht! Muss das wirklich alles sein?

Und selbst wenn "ja":

- Reduzierung von SLrad=2 zu SLrad=1 verringert die Komplexität schon mal etwas, ohne wirklich viel Unterschied zu machen
- EEDI2 ist schon langsam. NNEDI2/3 könnten auf Multicores schneller sein - die verwenden "internes" Multi-Threading, und bieten auch Parameter für etwas schnellere Verarbeitung, insbesondere NNEDI3. Allerdings, dafür hat beta2 keine offiziellen Parameter - bis ich da (vielleicht) mal was mache, verweise ich auf die "QTGMC" Modifikation von -Vit-.

Zitat von Menedas

Du meintest 4 Pixel Overlap reichen. Warum hast du dann jetzt 16 im Beispiel?

2 oder 4 Pixel für einfache Kernel-Filter, oder ähnliches. In TGMC_beta2 wird MVTools mit einer blocksize von 16x16 verwendet. Deswegen 16 Pixel overlap.

Zitat

StaxRip has crashed!
System.AccessViolationException: Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben.

Speicherfehler / SetMemoryMax.

Zitat

Also ich habs mal genau so probiert, also SetMTmode(5,2) in die erste Zeile des Skripts plus SetMTmode(2) oder nichts vor TGMC, habe dann aber immer nur eine Last von um 80%. Fehlen also fast 20%.

Ich merke auch, dass MTmode mit 2 threads desöfteren nicht ganz so effektiv ist. Beste Werte bekomme ich meistens mit 4, 6 oder 8 Threads.
Allerdings ja auch auf einem 4-Kerner mit insgesamt 8 logischen SMT Threads. Bei Dir - zwei Kerne mit insgesamt 2 logischen SMT Threads, da kann sich das schon anders verhalten. (Zu dieser CPU-Generation hab' ich kaum eigene Erfahrungswerte - ich hab' ja einen technischen Zehn-Jahres-Sprung von Celeron-1Core auf Nehalem-4CoreHT gemacht.)

Zitat

Zu NNEDI2 hatte ich doch mal mit dir eine kleine Diskussion. In meinem Videobeispiel hatte das deutlich schlechtere Ergebnisse geliefert als EEDI2

Ja, ich weiß. Aber das sagt trotzdem nicht, dass EEDI2 "besser" wäre. Es ist nur "anders". EEDI2 ist insgesamt erfolgreicher beim "Verbinden" von fehlenden Bildinhalten. Aber: EEDI2 produziert auch eindeutig mehr Bildfehler (*falsche* Verbindungen, und Streu-Pixel). Die Gesamterscheinung ist weniger "natürlich". Und außerdem ist EEDI2 langsamer, deutlich langsamer als NNEDI2 oder NNEDI3.

Du hast Dein Beispiel zu EEDI2 -vs- NNEDI2 gezeigt. Okay. Ich hab auch ein Beispiel.

------- Source --------------- EEDI2 --------------- NNEDI2
[Blockierte Grafik: http://img831.imageshack.us/img831/8392/shimmertest1source.th.png][Blockierte Grafik: http://img178.imageshack.us/img178/6489/shimmertest2eedi2.th.png][Blockierte Grafik: http://img524.imageshack.us/img524/7398/shimmertest3nnedi2.th.png]

[Blockierte Grafik: http://img215.imageshack.us/img215/9591/lotd1source.th.png][Blockierte Grafik: http://img594.imageshack.us/img594/3995/lotd2eedi2.th.png][Blockierte Grafik: http://img139.imageshack.us/img139/3048/lotd3nnedi2.th.png]

Sollte wohl reichen als Beleg, dass EEDI keinesfalls "generell besser" ist als NNEDI ...

Speed:

EEDI2 ist immer single-threaded. NNEDI2 kann beliebig viele Threads verwenden.

Reines Bobbing von 720x576i:

EEDI2(maxd=16) : 6.3 fps

NNEDI2(threads=1/2/4) : 9.6 / 17.0 / 27.0 fps

Mit nur einem Thread ist NNEDI2 50% schneller als EEDI2. Mit 2 Threads ist's fast dreimal so schnell.
Qualitätsmäßig ist also eher ein "you win here, you lose there" Spiel. Und geschwindigkeitsmäßig ist EEDI2 hoffnungslos unterlegen.

Geschwindigkeit war doch das ursprüngliche Problem, oder?

Du wirst wohl irgendeinen Kompromiss schließen müssen. Wenn alle Parameter auf Maximum aufgedreht sind, und von den möglichen Filter-Alternativen auch noch die langsamsten Varianten präferiert werden, dann ... sollte man sich nicht über unterirdische Geschwindigkeit beschweren. Als i-Tüpfelchen müsstest Du eigentlich noch x264 --preset placebo verwenden - dann passt alles zusammen.