So last night I started 2 conversions of SD content with QTGMC@Placebo in 10 bit and a few other filters, as usual, without MT modes and ~3 GiB memory limit. Expecting the typical 0.8 to 0.9 fps in ffmpeg while encoding with x264 I thought I was haluzinating when the counter said 5.0 fps. "Oh my, what filters did I comment out accidentally? Or is avisynth serving blank frames?" Looking at the memory consumption in task manager reinforced my belief: One ffmpeg process with ~3 GiB and one at meagre 175 MiB. LOL! Whatever it was doing, x264 alone would consume so much memory. Well let's see tomorrow...
The next day I opened the produced file and to my surprise - actually a bit of a shock - it looked perfect, like the other encodes. Waaaaaaiiiiiit.... I can get a 6x speed-up at a fraction of the memory use with no quality loss? Someone tell me how to reproduce this! I could run a lot more processes in parallel, too!
CPU: 2 core mobile Haswell @ 2.3 Ghz
RAM: 8 GiB
AviSynth+ r2508 MT, x64
I've hear VapourSynth is a lot faster with some scripts. So maybe AviSynth+ is just as fast, if it wasn't for a bug that gets triggered most of the time in complex scripts? The cache sub-system comes to mind here. Have you made a similar experience?
+ Reply to Thread
Results 1 to 5 of 5
If it's not repeatable , very likely user error somewhere. Either before or after (e.g. maybe 5fps is "normal" and your made mistake with older runs) something is different
eg. You misread or entered a wrong value, or forgot something - maybe some setting wasn't passed in ffmpeg etc..., maybe you changed different dll etc...
It's simple enough to run some quick tests / benchmarks with avsmeter / ffmpeg etc...
For QTGMC alone, avisynth+ x64 was still the fastest in my tests. The problem is with different scripts/filters, different prefetch values are required for "best" performance. If you find that value, it's the fastest. But you have to run many tests and the "ideal" prefetch value changes under different conditions (you can get thread thrashing and poor scaling, such as +25-50% more cpu usage for only +1-2% speed) . For vapoursynth, the threading is pretty much automatic. But some functions are faster in avisynth+ 64 MT, some are faster in vapoursynth
Another thing is older 32bit avisynth mvtools2 versions had a memory issue where you'd get a steep falloff in performance once hitting ~2GB , some type of memory leak. Not an issue with 64bit, or with newer pinterf mvtools2 branch , but you'd see some performance issues like this graph
So if you "upgraded" to the mvtools2/pinterf branch, and just recently switched to avisynth+64 , that could easily explain it too if you were around that memory mark.
That issue was "fixed" even in 32bit with the pinterf mod
Thx, I didn't expect any answers and the hint at MVTools is the best I have. I've tried the same script with AVSMeter and with ffmpeg and performance figures were the same as always, somewhere around 1 fps. Encoding settings also did not change since years (literally). And visually I could tell that QTGMC was working. It really looks like a one time 500% speed boost, but in your position I would also assume a user error, especially when doing something after a beer at 11 PM.
I am using MVTools from pinterf's branch: https://github.com/pinterf/mvtools/releases/tag/184.108.40.206