TGMC CPU nicht voll ausgelastet

Nein ... Speicher Managment. SetMTmode braucht einfach mehr Speicher. Ist der Cache-Wert von Avisynth zu gering, gibt's erst Zeitlupen-Geschwindigkeit, dann einen Crash. Ist der Wert zu groß, gibt's entweder Zeitlupengeschwindigkeit wg. Auslagerung, oder einen Crash wegen dem 2GB-Limit.

Vielleicht hat auch StaxRip irgendeine "Besonderheit", die ich nicht auf dem Radar habe. All' diese Klicki-Klick-GUIs finden bei mir kaum jemals Anwendung, deswegen weiß da nicht so viel drüber. (Ich weiß hauptsächlich, dass die Leute andauernd irgendwelche Probleme mit diesen GUIs haben...)

Auch Arbeitsspeicher wird heiß, wenn er exzessiv benutzt wird (ständig Daten hin und her kopiert und verändert werden). Bei leicht übertakteten Systemen kann das durchaus dazu führen, dass mal einige Speicherzellen inhaltlich durcheinanderkommen. Sind das zufällig solche, in denen Programmcode oder Adressen stehen, sind Abstürze die Folge.

Und das mit ColorBars.Subtitle in 8 Threads musst du halt mal ausprobieren... ich wittere da einen "Glitch" (amüsantes bis ärgerliches Fehlverhalten) - vielleicht mehrere Untertitelanzeigen, wo eigentlich nur eine sein sollte?

Zitat von Didée

Als i-Tüpfelchen müsstest Du eigentlich noch x264 --preset placebo verwenden - dann passt alles zusammen.

Noch "kompromißloser" wäre der Einsatz von QTGMC mit dem Preset Placebo anstatt TGMC.
Bislang gab ich auch EEDI2 den Vorzug, nunmehr NNEDI3, wohl ein verbessertes NNEDI2.

Das Colorbars-Beispiel war nur zur Verdeutlichung wie MT() eigentlich funktioniert. Man erwartet dieses Ergebnis nicht unbedingt ... beim ersten Mal war ich auch etwas überrascht, bis dann der AchSo!!-Effekt eingesetzt hat.

Es wird nicht die Arbeit eines Filters auf N Threads verteilt. Vielmehr wird N-mal eine Kopie des Filters gleichzeitig ausgeführt. Das ist ein Unterschied. (Plugins mit globalen Variablen...)

Außerdem ein indirekter Fingerzeig, dass man im Fall von modulo-Problemen mittels Info() der Sachlage auf den Grund gehen kann.