Avisynth Slow Encoding Bug when NOT using MT!

[VideoFanatic]

I sometimes get a bug when using MT where the video will encode at less than 1fps for no reason. But if I encode another Non-MT video such as re-encoding a 1080i video to 720p then restart the MT encoding, it will start encoding at the correct speed.

However lately I've noticed this slow encoding bug in non-MT! I thought that should never happen in non-MT? Here's my script for upscaling a 576i video to 1080p (I do this to prevent quality loss when uploading SD clips to YouTube):

DGSource("W:Video.dgi")
AssumeTFF() 
QTGMC(Preset="Super Fast")
McTemporalDenoise(settings="low", interlaced=false)
Crop(16,2,-20,-8)
nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=1920, fheight=1080)

Sometimes the slow encoding bug in MT is causing by 2 x264.exe processes running at once which is a glitch. I close the processes and restart making sure there's only 1 process and it works fine. But there's only 1 process running with the script above so that problem isn't an issue here. Any idea why it's encoding far slower than it should be? It's encoding at less than 1fps when it should be encoding at 5fps.

[LigH.de]

I sometimes get a bug when using MT where the video will encode at less than 1fps for no reason.

Certainly wrong: Sudden slow speed always has a reason. You just have to find it. May it be full physical RAM for one of the related processes so that Windows starts using virtual RAM (i.e. disk swapping)?

[VideoFanatic]

RAM usage of 7.28GB out of 8GB RAM installed. What do you mean by swapping? I've also set Virtual member page file to system managed.

[LigH.de]

Yes, this "page file" gets used when a process requests RAM, but too much of it is already in use, so a part of the RAM already used by a process gets written into the page file, and that will probably be some of the frames AviSynth just calculated and one of the encoders needs for compression. Then it has to read it from the page file instead from RAM. And this is, of course, a lot slower.

Very complex scripts need more RAM for the AviSynth process calculating the filters. The more MT threads you want to use, the more RAM it needs.

Very complex encoding settings need more RAM for the encoder process. Slowest presets are not always best suited.

[sneaker]

Could this be related?
http://forum.doom9.org/showthread.php?t=172744

[VideoFanatic]

Yes thanks. That's basically the same issue. Glad to know I'm not the only one having that problem. Still doesn't seem to be a fix for it though. I read all the posts there.

[jagabo]

Your not using SetMtMode()?

[VideoFanatic]

No. MT always crashes for me on HD footage or when upscaling SD to HD.

[hello_hello]

Yes thanks. That's basically the same issue. Glad to know I'm not the only one having that problem. Still doesn't seem to be a fix for it though. I read all the posts there.

The version of QTGMC linked to in post #13 in the doom9 thread tends to behave itself better for me. There's still sometimes slowdowns, but they seem to be less frequent.

Other than that I always add -stitchable to the x264 command line so if an encode does run slow I can abort it and use MKVMergeGUI to split the encoded video on a keyframe near the end, then I add Trim() to the script in order to re-commence encoding from there. The second attempt tends to behave itself and I append the encoded video later. Hopefully someone will work out what's causing it eventually.

[VideoFanatic]

Tried that and it doesn't seem to make a difference to a new problem I'm having where I've got a 544 x 576 video I'm encoding to 720 x 576.
I can use any QTGMC preset but if I also use McTemporalDenoise Low preset then the encode always fails. Yet the McTemp Medium preset encodes fine! Cropping the video or not makes no difference.

setmtmode(5,6)
mpeg2source("M:\Video.d2v")
setmtmode(2)
McTemporalDenoise(settings="low", interlaced=true)
AssumeTFF() 
QTGMC(Preset="Slow")
Crop(10,2,-10,-8) 
nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=720, fheight=576) 
SeparateFields() SelectEvery(4,0,3) Weave()

[LigH.de]

Try it again, starting the script with

setmtmode(5,4)
...

Only 4 instead of 6 threads. Does it still crash (probably due to a lack of memory)?

If you run the script via AVSMeter, how much RAM consumption does it report for the AviSynth process, with either 6 or 4 threads? Also try to use a good Task Manager (like SysInternals ProcessExplorer) to monitor the process using AviSynth, it may be interesting to learn about the RAM requirements over the processing time.