Encoding slowdown

[hello_hello]

I've pretty much finished what I wanted to get done for the moment, but I'll have to build a new PC and install a new OS for VapourSynth. I don't think it runs on XP. Mind you I was planning on doing exactly that this week but between getting sick and spending a lot more time messing around with encoding than I thought I would, it looks like it'll be next week now.

I haven't read your more recent cachetest instructions thoroughly yet, but do you still think it'd be worth trying? I don't mind experimenting a bit more in a few days... once I've had a break from it.

[StainlessS]

If same problems exhibited by Avisynth prior to v2.6Alpha3 (inclusive) then Cachetest (cache dont work every 30th frame) problem
is probably not helpful. (I'm guessing, think that is what you suggested as being true).

EDIT: I have however downloaded pretty much everything mentioned in this and associated threads, and will play a little with CacheTest dll.

[kuchikirukia]

Try VapourSynth's QTGMC if you need to do "productive" work and cannot wait for a fix.

Does VapourSynth have a usable installer and syntax yet?

<3 MeGUI. It's a god-tier program that makes it easy to get into Avisynth. There's no need to try to piece together an idea of Avisynth from scratch from a manual, you can just watch how MeGUI changes the script when you check various boxes or pick various settings from a dropdown. While the Avisynth language is powerful, by calling scripts it can be reduced to the simplicity of:
<input>
<filter>

VapourSynth's "Getting Started," is "Learn Python."
I think I'll use Avisynth and Trim.

[hello_hello]

I think I've been experiencing this problem on and off for quite a while. Probably for as long as I've been using QTGMC. I'm not sure whether it's happening more regularly now or if I'm just more aware of it.... probably a bit of both.... and maybe I'm more likely to use a script for encoding that'll cause a slowdown these days.

I'll have to ask Zathor how MeGUI determines the processing rate it displays because if nothing else, I've become aware it's not terribly accurate. The rate displayed appears to be an average taken over a considerable period of time. As a result if I encode the first section of a video without any processing (via Trim), it might run at 30 or 40 fps, then when encoding reaches the first frame processed by QTGMC it might drop to 7fps, but the rate displayed by MeGUI doesn't change quickly. It gradually decreases over minutes which makes it fairly useless for determining if the speed dropped to a "normal" level or if it tanked. It might also be a reason why I've not always noticed slowdowns in the past.
Unless encoding started off slower than it should to make it obvious, for the testing I've been doing recently I'd encode a specific amount of video each time and check MeGUI's log file for x264's reported encoding speed. There's probably a better way to do it.

[real.finder]

I think I've been experiencing this problem on and off for quite a while. Probably for as long as I've been using QTGMC. I'm not sure whether it's happening more regularly now or if I'm just more aware of it.... probably a bit of both.... and maybe I'm more likely to use a script for encoding that'll cause a slowdown these days.

I'll have to ask Zathor how MeGUI determines the processing rate it displays because if nothing else, I've become aware it's not terribly accurate. The rate displayed appears to be an average taken over a considerable period of time. As a result if I encode the first section of a video without any processing (via Trim), it might run at 30 or 40 fps, then when encoding reaches the first frame processed by QTGMC it might drop to 7fps, but the rate displayed by MeGUI doesn't change quickly. It gradually decreases over minutes which makes it fairly useless for determining if the speed dropped to a "normal" level or if it tanked. It might also be a reason why I've not always noticed slowdowns in the past.
Unless encoding started off slower than it should to make it obvious, for the testing I've been doing recently I'd encode a specific amount of video each time and check MeGUI's log file for x264's reported encoding speed. There's probably a better way to do it.

use http://forum.doom9.org/showthread.php?t=165528

this will show the real speed and give you a lot of options for testing

and I suggest using MP_Pipeline in the encoding, it will keep you away from a lot of problems, if you see it complex, then use it simply like this


MP_Pipeline("""
### platform: win32
your usual script
### ###
""")


that will keep avs processes away from x264 process and that will speed your encoding and keep you away from a lot of crashes or deadlock

[Groucho2004]

I think I've been experiencing this problem on and off for quite a while. Probably for as long as I've been using QTGMC. I'm not sure whether it's happening more regularly now or if I'm just more aware of it.... probably a bit of both.... and maybe I'm more likely to use a script for encoding that'll cause a slowdown these days.

I'll have to ask Zathor how MeGUI determines the processing rate it displays because if nothing else, I've become aware it's not terribly accurate. The rate displayed appears to be an average taken over a considerable period of time. As a result if I encode the first section of a video without any processing (via Trim), it might run at 30 or 40 fps, then when encoding reaches the first frame processed by QTGMC it might drop to 7fps, but the rate displayed by MeGUI doesn't change quickly. It gradually decreases over minutes which makes it fairly useless for determining if the speed dropped to a "normal" level or if it tanked. It might also be a reason why I've not always noticed slowdowns in the past.
Unless encoding started off slower than it should to make it obvious, for the testing I've been doing recently I'd encode a specific amount of video each time and check MeGUI's log file for x264's reported encoding speed. There's probably a better way to do it.
Agree with real.finder. You're making things unnecessarily difficult for yourself. By including the encoder and a Gui frontend in your testing scenario, the complexity increases significantly and results will be even more random. The problem clearly is with the frame-serving so you should test just that.
AVSMeter even allows you to export the performance data to a csv file for import in a spread sheet program so you can create pretty diagrams like here (http://forum.doom9.org/showthread.php?p=1736090#post1736090). :D

[hello_hello]

I suspect the encoding does sometimes change the result, but I'm not sure that means it should be excluded from all testing. Afterall, in the end we use Avisynth to encode. Anyway.....

I gave AVSMeter a quick spin on the problem sample/script and it confirmed what I already knew. I didn't bother running the encodes to the end. Without Trim at the end of the script vs Trim(50,0) at the end of the script.

http://s21.postimg.org/jxmml3y43/test1.jpg (http://postimg.org/image/jxmml3y43/)

http://s8.postimg.org/hplyhwbwh/test2.jpg (http://postimg.org/image/hplyhwbwh/)

PS. When I ran the above encodes it was using the second PC and I forgot to restore my current Avisynth plugins folder first, so the above encodes were run with Avisynth 2.6.0.6 and the original QTGMC plugins. I guess that's another combination tested.

I'm still not motivated to get back into much more testing yet but I might need to create pretty diagrams when I do. Unless there's a way to get AVSMeter to run a complete script but only meter part of it? Because when I tried the following script:

AssumeTFF()
Trim(0,719).ChangeFPS(50,1).crop(20, 8, -18, -8).Spline36Resize(640,480)\
++Trim(720,1784).QTGMC(sharpness=0.7).crop(20, 8, -18, -8).Spline36Resize(640,480)
gradfun3()

and then compared it to this:

AssumeTFF()
Trim(720,1784).QTGMC(sharpness=0.7).crop(20, 8, -18, -8).Spline36Resize(640,480)
gradfun3()

I could visually see frames 720 to 1784 were being processed about 1fps to 1.5fps faster the second time, but naturally the average/min/max frame rates don't reflect that. Mind you that's not a huge difference, although that's the script I'm sure has tanked at times after frame 720 while encoding. I'll have to experiment some more with that one. That's the problem.... aside from the original sample I posted the issue isn't 100% repeatable. I can abort an encode that's obviously running slow and when I restart it it runs at twice the speed from start to finish. It'll be interesting to see if when I test a script with AVSMeter multiple times it'll always run at the same speed.

[hello_hello]

and I suggest using MP_Pipeline in the encoding, it will keep you away from a lot of problems, if you see it complex, then use it simply like this


MP_Pipeline("""
### platform: win32
your usual script
### ###
""")


that will keep avs processes away from x264 process and that will speed your encoding and keep you away from a lot of crashes or deadlock

While MP_Pipeline has helped in the past I'm certain there's been a few occasions where it didn't (I had to use Trim instead), but isn't kuchikirukia using avs4x264mod and wouldn't that also be keeping avs processes away from x264, or is it not that easy?

[Groucho2004]

Afterall, in the end we use Avisynth to encode.:confused:

Unless there's a way to get AVSMeter to run a complete script but only meter part of it?
Run the whole script, export to CSV, import to LibreOffice (or MS Excel), select the rows with the frames you're interested in, create a graph.

[Groucho2004]

isn't kuchikirukia using avs4x264mod and wouldn't that also be keeping avs processes away from x264, or is it not that easy?
avs4x264mod or any other piping tool will indeed run x264 in a separate process.

[hello_hello]

:confused:

I was simply wondering if frame serving to an encoder such as x264, rather than running a script in AVSMeter, might sometimes produce a different result. If that's impossible and Avisynth will process the video at the same rate either way, then obviously there's no point encoding while testing, but I assume real.finder didn't suggest trying to keep the Avisynth and x264 processes separate if doing so can't make any difference.

Run the whole script, export to CSV, import to LibreOffice (or MS Excel), select the rows with the frames you're interested in, create a graph.

Maybe early next week when I'm motivated again, although I'm not sure if it'll achieve much. I've provided one sample for which the problem is 100% repeatable, and from there it'll require someone more clever than I am to work out what's wrong and how to fix it. I might be able to create a few more samples/scripts that are likely to cause slowdowns if it helps, but so far nothing else has been 100% consistently slow.

[Groucho2004]

I was simply wondering if frame serving to an encoder such as x264, rather than running a script in AVSMeter, might sometimes produce a different result.
The only difference I can think of is when the process memory consumption (Avisynth + x264) gets close to the limit of 2GB. The advantage of using AVSMeter is that it tells you how much memory is allocated by Avisynth alone. If that is already at ~1.5 GB, adding the encoder into the process can have the effects you are seeing. Sending the frames through stdout to x264 eliminates this particular problem.

[Groucho2004]

AssumeTFF()
Trim(0,719).ChangeFPS(50,1).crop(20, 8, -18, -8).Spline36Resize(640,480)\
++Trim(720,1784).QTGMC(sharpness=0.7).crop(20, 8, -18, -8).Spline36Resize(640,480)
gradfun3()

and then compared it to this:

AssumeTFF()
Trim(720,1784).QTGMC(sharpness=0.7).crop(20, 8, -18, -8).Spline36Resize(640,480)
gradfun3()

I could visually see frames 720 to 1784 were being processed about 1fps to 1.5fps faster the second time, but naturally the average/min/max frame rates don't reflect that.
AVSMeter records the timing for each frame (if the average FPS < 50) and the min/max values will definitely reflect that.

[real.finder]

I was simply wondering if frame serving to an encoder such as x264, rather than running a script in AVSMeter, might sometimes produce a different result. If that's impossible and Avisynth will process the video at the same rate either way, then obviously there's no point encoding while testing, but I assume real.finder didn't suggest trying to keep the Avisynth and x264 processes separate if doing so can't make any difference.



Maybe early next week when I'm motivated again, although I'm not sure if it'll achieve much. I've provided one sample for which the problem is 100% repeatable, and from there it'll require someone more clever than I am to work out what's wrong and how to fix it. I might be able to create a few more samples/scripts that are likely to cause slowdowns if it helps, but so far nothing else has been 100% consistently slow.

did you see this http://forum.doom9.org/showthread.php?p=1736090#post1736090 ?

Reel.Deel use QTGMC with these testes, and avs 2.6 slowdown from > 20 fps to < 20 fps

did you try avs+ ?

[hello_hello]

I'm fairly certain when I found the problem with the sample I've been using for testing in this thread, switching to Avisynth+ was one of the first things I tried. MeGUI was using Avisynth+ as it's own "portable" Avisynth at the time, but which version it was using..... I'm not sure. I could maybe hunt through old log files to see if I can work it out but I wouldn't trust that to be completely accurate anyway because I switch versions now and then anyway and there's log files on two PCs.

I'm not sure it's the same problem as Avisynth+ either. I'm reasonably sure there's no "slowdown" taking place. In my case I think encoding tends to progress at normal speed, then suddenly drop by half or more. I say "I think" because I've been watching the rate displayed by MeGUI but it's not accurate at any given moment. Encoding may progress along at 30fps and suddenly drop to 10fps (as an example), but the rate being displayed by MeGUI drops ever so slowly.... so it looks like there's a gradual slowdown when in fact there was a sudden change in speed..

I base much of that on the fact certain encodes obviously start off at a reduced speed and stay at the reduced speed until they're done, rather than start off much faster than they finish, but I don't know for certain there's no slowdowns taking place. The few tests I've run with AVSMeter seem to confirm it's a sudden speed change, but I've not performed extensive tests with it yet.

[kuchikirukia]

I don't know why you're using such vague metrics such as "feel" of whether an encode has slowed down. L-SMASH should not be creating and destroying threads. FFMS2 should not be running at ridiculous CPU util. These correspond to slowdowns.
If L-SMASH is going Christmas or FFMS2 is spiking CPU, Avisynth is choking.

It does this in QTGMC 3.32 and with Avisynth+, 2.6MT, and 2.6. Since none of the changes from 3.32 were made to address this, I don't know why you're flipping through scripts at random. Do you think someone accidentally fixed this?
Just use Trim until a programmer decides to chase this down. You don't need to fill this thread with meaningless garbage as to whether you "feel" an unstated script using unstated settings is "working." You don't have a baseline and you're not looking at anything that might give you a clue of what's going on.

[c8rag]

I had this problem too, so I registered this account.:p This problem is unlike the Avisynth+ slowdown.(https://github.com/AviSynth/AviSynthPlus/issues/63)

My setting is Avisynth official 2.6.0.6, QTGMC 3.33 Mod20151023, nnedi_0.9.4.20, others are recommended here (http://forum.doom9.org/showthread.php?p=1733741#post1733741).

I tried ICL10 built by Groucho2004, got same result; QTGMC 3.33 original , same result; with or without avstp.dll, same result.

nnedi_0.9.4 can fix this problem in my test , also the trim method is ok.

[c8rag]

with 0.9.4
http://s10.postimg.org/v6pcdv84n/image.png
with 0.9.4.20
http://s29.postimg.org/4x0ndjgt1/9420.png

[AzraelNewtype]

Lemme help you out there:

0.9.4
http://s10.postimg.org/fxzf03eg5/image.png (http://postimg.org/image/fxzf03eg5/)

0.9.4.20
http://s29.postimg.org/ormoznw0j/9420.jpg (http://postimg.org/image/ormoznw0j/)

Guess it didn't like the hotlinking.

[hello_hello]

I don't know why you're using such vague metrics such as "feel" of whether an encode has slowed down. L-SMASH should not be creating and destroying threads. FFMS2 should not be running at ridiculous CPU util. These correspond to slowdowns.
If L-SMASH is going Christmas or FFMS2 is spiking CPU, Avisynth is choking.

Read my post again. I was asked about Avisynth+ and I replied I'm fairly sure the problem isn't one involving gradual slowdowns as was the issue there, but I can't be certain that's always the case because the encoding rate displayed by MeGUI changes quite gradually even when the actual speed drops quite quickly.

It does this in QTGMC 3.32 and with Avisynth+, 2.6MT, and 2.6. Since none of the changes from 3.32 were made to address this, I don't know why you're flipping through scripts at random. Do you think someone accidentally fixed this?

I'm fairly sure I've also experienced slow encoding speeds on occasion with DGDecode. I wasn't flipping through scripts at random, I was testing earlier versions of Avisynth with the known problem sample/script each time while attempting to find another example of the problem that'd also be 100% repeatable.

You don't need to fill this thread with meaningless garbage as to whether you "feel" an unstated script using unstated settings is "working." You don't have a baseline and you're not looking at anything that might give you a clue of what's going on.

If anything, I've been asking how to more accurately test the speed of particular scripts so I don't need to guess what's going on, and I haven't used the word "feel" anywhere so I've no idea what you're on about.

[hello_hello]

I had this problem too, so I registered this account.:p This problem is unlike the Avisynth+ slowdown.(https://github.com/AviSynth/AviSynthPlus/issues/63)

nnedi_0.9.4 can fix this problem in my test , also the trim method is ok.

I'll confess given kuchikirukia has instructed me to cease testing I wasn't sure if I should to try a different version of nnedi3, but I gave it a spin. I had tested at least one earlier version in the past with no success, but I thought it couldn't hurt to try again.

I don't know how or why but when I initially switched to nnedi3 version 0.9.4 (I'd been using 0.9.4.10) my test sample/script behaved perfectly. It encoded at normal speed and there were no ffms2 CPU spikes. It's CPU usage stayed very low. I ran the test encode with the same result three times in succession. I got excited....

I switched to the second PC to try again but unfortunately this time 0.9.4 made no difference. In fact one of the plugin folders I'd created for testing last week included nnedi3 0.9.4, but I tested it again and encoding speed was still slow.

Most disappointing was returning to this PC to discover the problem had returned. I know it sounds a bit mental and it's enough to make a person question their grip on reality, but 0.9.4 fixed the problem, and then it didn't. :(

Anyway, if you registered and posted here specifically to suggest a fix, the effort is very much appreciated.

[AzraelNewtype]

If anything, I've been asking how to more accurately test the speed of particular scripts so I don't need to guess what's going on, and I haven't used the word "feel" anywhere so I've no idea what you're on about.

AVSMeter with the full logging is what you want. Especially the new fun csv output that lets you make nice graphs with minimal effort.

Also, it's very strange that someone advocating a solution that amounts to "this rock repels tigers" is all of a sudden very concerned enough about objective, rational thinking to complain to you about it more than once, but I digress.

[real.finder]

I did a test and...

ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToYV12()
QTGMC(InputType=1, Ezdenoise=2)
LSFMod(strength=66)
gradfun3()

http://i.imgur.com/mwsuZ4K.png

ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToYV12()
QTGMC(InputType=1, Ezdenoise=2)
LSFMod(strength=66)
gradfun3()
Trim(50,0)

http://i.imgur.com/BMnHIWR.png

wow!

[StainlessS]

Perhaps better use pixel_type="YV12" in colorbars rather than ConvertToYV12, take that effect out of numbers.

[real.finder]

Perhaps better use pixel_type="YV12" in colorbars rather than ConvertToYV12, take that effect out of numbers.

I did (and usually do) this because colorbars output is Rec. ITU-R BT.801-1 (http://avisynth.nl/index.php/ColorBars) for YUV

Nothing to do with this here, but I used to use it like this

[AzraelNewtype]

What version of nnedi3 are you using for qtgmc there? That's probably important too, given c8rag's testing. Also, because I sort of misread his tests I did a little thing of my own and just tested some nnedi3 versions alone, not in the script, and lo!

http://i.imgur.com/eTFA2wuh.png (http://i.imgur.com/eTFA2wu.png)

Same nearly vertical dip c8rag was seeing in the script. Also, for the record, this was tested on an AMD cpu, and I guess the icl10 used for that build wasn't patched to not disable a lot of optimizations on AMD cpus, hence it being utter garbage by comparison.

Might try the same clip (this is real footage, not colorbars) with qtgmc and a couple of the nnedi3s, but I have a feeling it's just going to be roughly the same lines, but lower on the y-axis.

[kuchikirukia]

Does inputtype=1 even call nnedi3? nnedi3 usually spawns additional threads which I don't see.

E: Nope, it doesn't complain when I don't load the dll.
Since it does this under inputtype=1 as well as deinterlacing, it seems to be unrelated to nnedi3.


Oh, and hello_hello, my apologies for the rant. I misread your post and thought you were saying something you weren't. I read, "I'm not sure it's the same problem as Avisynth+ either. I'm reasonably sure there's no "slowdown" taking place," as, "I'm not sure there's the same problem (as we've been talking about) using Avisynth+. I'm reasonably sure there's no slowdown taking place." I didn't catch that you were referencing the separate problem in Avisynth+ r1779+ and thought you were throwing out info that conflicted with what I had seen while testing with Avisynth+. After having sat there for hours watching process explorer through dozens of tests and seeing Avisynth+ crap out time and again, I wasn't too happy to see what looked like, "Avisynth+ is fine."

[real.finder]

What version of nnedi3 are you using for qtgmc there? That's probably important too

NNEDI3_v0_9_4_20 x86 Release_Intel_XP_Core2_SSE4.2

[Groucho2004]

Also, for the record, this was tested on an AMD cpu, and I guess the icl10 used for that build wasn't patched to not disable a lot of optimizations on AMD cpus, hence it being utter garbage by comparison.
I'm not using the automatic CPU dispatcher for my ICL builds so there is no disadvantage for AMD CPUs.
Without seeing the script or which ICL NNEDI3 DLL you used I obviously can't tell you why you're experiencing this poor performance.

[AzraelNewtype]

Does inputtype=1 even call nnedi3? nnedi3 usually spawns additional threads which I don't see.

E: Nope, it doesn't complain when I don't load the dll.
Since it does this under inputtype=1 as well as deinterlacing, it seems to be unrelated to nnedi3.


Oh, right it obviously wouldn't, I'm an idiot.

I'm not using the automatic CPU dispatcher for my ICL builds so there is no disadvantage for AMD CPUs.
Without seeing the script or which ICL NNEDI3 DLL you used I obviously can't tell you why you're experiencing this poor performance.

The script was literally just a trim and nnedi3(field=-2). As for the dll, it's hard to say. The date I have on it is 8/1/2013, though I'm not sure if that's the date it was built before putting it into a zip or the date I unzipped it. If there's any symbols inside that could help you narrow down anything about it, the exact dll is here (https://dl.dropboxusercontent.com/u/21987967/nnedi3.dll). The version number is just 0.9.4.0.

[Groucho2004]

As for the dll, it's hard to say. The date I have on it is 8/1/2013, though I'm not sure if that's the date it was built before putting it into a zip or the date I unzipped it. If there's any symbols inside that could help you narrow down anything about it, the exact dll is here (https://dl.dropboxusercontent.com/u/21987967/nnedi3.dll). The version number is just 0.9.4.0.
Try the one from here (https://www.sendspace.com/folder/10dsem) (nnedi3_0.9.4_fturnmod.7z). Don't forget to also put fturn.dll (https://github.com/tp7/fturn/releases) into the same directory.

[c8rag]

I had this problem too, so I registered this account.:p This problem is unlike the Avisynth+ slowdown.(https://github.com/AviSynth/AviSynthPlus/issues/63)

My setting is Avisynth official 2.6.0.6, QTGMC 3.33 Mod20151023, nnedi_0.9.4.20, others are recommended here (http://forum.doom9.org/showthread.php?p=1733741#post1733741).

I tried ICL10 built by Groucho2004, got same result; QTGMC 3.33 original , same result; with or without avstp.dll, same result.

nnedi_0.9.4 can fix this problem in my test , also the trim method is ok.

I drew a wrong conclusion. I think the main reason of my problem is the source filter:ffms, I used 2.22RC2 updated by megui. Other versions works fine with nnedi3 0.9.4 or 0.9.4.20. Thanks for all your help.:p

[StainlessS]

c8rag, MeGUI (EDIT: Development) update server now issues filter:ffms v2.22 rather than 2.22RC2, dont know if there is much if any difference.

[hello_hello]

Does inputtype=1 even call nnedi3? nnedi3 usually spawns additional threads which I don't see.

E: Nope, it doesn't complain when I don't load the dll.
Since it does this under inputtype=1 as well as deinterlacing, it seems to be unrelated to nnedi3.

Howdy. I've been busy in the real world so away from this for a bit.

Thinking about it, you're probably right there (I don't want to mess around myself right now as I've got an encode running at the moment and I'd prefer to let it finish first) but that means so far I've seen two "impossible" things happen. When I first replaced nnedi3 with an older version in the auto-loading plugin folder it temporarily fixed the problem. At one stage simply putting cachetest.dll in that folder also fixed the problem. I haven't tried that again using this PC but I tried it with the second PC and it made no difference, however for one PC changing or adding a plugin to the auto-loading folder certainly did seem to make a difference even though the plugin in question wasn't being used.
I know that sounds mental and it makes me wonder if I'm going mad, but the 100% repeatable problem stopped happening right after I changed or added those plugins, even if only temporarily, and while I know that's the sort of co-incidence only PCs can manage, it's still a particularly bizarre co-incidence if that's all it was.

Oh, and hello_hello, my apologies for the rant. I misread your post and thought you were saying something you weren't.

I know I'd been stumbling about with testing a little and trying to describe that thoroughly resulted in a few posts that didn't really amount to much, so I guess at the time I had a "I'm being told off for trying" moment, but it's all good. Cheers.

It's kind of hard for me as for ages I "suspected" there was a problem, and then I became sure of it even though I could never reproduce it, but this thread (with your help) is the first time I've reached the stage where I can at least be sure there is an Avisynth problem that, as I've also long suspected, doesn't have anything to do with how much RAM I have installed or support for XP having ended, but unfortunately I can't do much aside from maybe trying different versions of plugins or different plugin combinations in the hope maybe that's where the problem lies.

I drew a wrong conclusion. I think the main reason of my problem is the source filter:ffms, I used 2.22RC2 updated by megui. Other versions works fine with nnedi3 0.9.4 or 0.9.4.20. Thanks for all your help.:p

I'll be interested to learn if that fixes it for good, or if it's some sort of co-incidence, given for me I'm sure the problem can also occur when decoding with L-Smash and DGDecode.
I'm certain for me changing ffms2 versions has made no difference in the past. I'm also sure early on switching to L-Smaszh was one of the first things I tried. I went back to using ffms2 2.20 for quite a while after having a problem with 2.21 or 2.22RC and I'm quite sure I tested again after updating to 2.22 recently... with no change.

[real.finder]

after I edit MPP (http://forum.doom9.org/showpost.php?p=1746479&postcount=235) I did some testing in avs MT

and your script is ok but with some complex scripts I got crash in the beginning of encoding or deadlock later, and some times every thing running OK (with the same script of course)

and after that I did some searches and find this http://forum.doom9.org/showpost.php?p=1716446&postcount=979

I know you not using MT but that maybe has related to your problem, Especially that the change I did here (http://forum.doom9.org/showpost.php?p=1743994&postcount=13) is nothing but switch from masktools2 function to removegrain one in some lines

so, I think it's masktools2 issue

[hello_hello]

real.finder,
The modification you made to the QTGMC script stopped the problem from occurring with the sample I've been using for testing (the slow speed is pretty much 100% repeatable with QTGMC 3.33d) but the problem hasn't gone away entirely. I'm certain I've had encodes running at half speed using your modified QTGMC and sometimes after aborting the encode and starting again it'll run fine, or I've used Trim to continue encoding from where it stopped and it's continued at normal speed.

It wouldn't surprise me if it's a masktools2 issue though, or some other plugin for that matter. I'm fairly sure I tested using different versions of masktools2 at one stage but sometime fairly soon I'll try again just to be sure. There's another issue I sometimes have which is mostly a problem of artefacts when using SRestore, but I'm certain I've seen similar artefacts with QTGMC, only for QTGMC they're less common and fairly minor. I use SRestore for double blend removal now and then, and mostly it works well, but occasionally artefacts will appear (http://forum.doom9.org/showthread.php?p=1696179&highlight=srestore#post1696179) for a single frame and for some videos it happens so much it's more annoying than the blending I'm wanting to remove. I tried ExBlend and FixBlendIVTC but the same thing happened. I suspect it might be a plugin problem and the four scripts all have masktools2 in common, but then again it could be completely unrelated to the issue here. When encoding speed slows using QTGMC it doesn't seem to cause the video to be processed any differently, just slower.

[VideoFanatic]

I'm using Avisynth 2.6 MT, QTGMC 3.31, by Vit (2011), mvtools2.dll (2.6.0.5). I've got a 544 x 576 MPEG2 video I'm encoding to 720 x 576.
I can use any QTGMC preset but if I also use the McTemporalDenoise Low preset then the encode always fails. Yet the McTemp Medium preset encodes fine! Cropping the video or not makes no difference. Here's my script:


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()

[Groucho2004]

I'm using Avisynth 2.6 MT, QTGMC 3.31, by Vit (2011), mvtools2.dll (2.6.0.5). I've got a 544 x 576 MPEG2 video I'm encoding to 720 x 576.
I can use any QTGMC preset but if I also use the McTemporalDenoise Low preset then the encode always fails. Yet the McTemp Medium preset encodes fine! Cropping the video or not makes no difference. Here's my script:


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()

QTGMC() combined with McTemporalDenoise() using 6 threads will exhaust your available memory very quickly.
Run the script through AVSMeter and tell us what happens.

[VideoFanatic]

I don't know how to do that.

[StainlessS]

I don't know how to do that.

Suggest that you download AVSMeter, and read the docs, then you would. :)

[VideoFanatic]

I dragged the avs file into AVSMeter.exe. The script is running. Do I have to wait 3 hours for it to finish? Then what do I do? What info do you need?

[Groucho2004]

How much physical memory is it using? Is it climbing/constant?

I suggest you set a time limit (30 minutes, for example) and create a log file which you can post on pastebin. Command line would be:
avsmeter script.avs -log -timelimit=1800

[VideoFanatic]

I opened AVSMeter in CMD. When I then try to run this it says "M:Working" is not recognized as an internal or external command, operable program or batch file:
M:\1Working Videos\Impact 2015\Impact 2015 Nov 18.avs -log -timelimit=1800

[StainlessS]

I presume that path to AVSMeter is in your path (and reboot may be necessary).

Also, ensure that name of avs file is enclosed in quotes as it contains SPACES.

EDIT: Also, is that '1' supposed to be there ? [M:\1Working Videos\Impact 2015\Impact 2015 Nov 18.avs]

EDIT: Something like

AVSMeter.Exe "M:\1Working Videos\Impact 2015\Impact 2015 Nov 18.avs" -log -timelimit=1800

[VideoFanatic]

Got it running now. So where does AVSMeter save the log to?

[StainlessS]

Documentation does not seem to specify output log location, suggest inspect,
same directory as "avs" file,
same directory as "AvsMeter.exe"
"C:\" directory.
"C:\Documents And Settings\YOUR NAME\"

[Groucho2004]

So where does AVSMeter save the log to?Same directory as the script.
I'll have to add that info to the documentation.

[VideoFanatic]

Log is attached.

[Groucho2004]

Log is attached.
It may take days for the attachment to be approved. Please post it to pastebin.com.

[VideoFanatic]

Too many characters for pastebin. Google Drive: https://drive.google.com/file/d/0B7SrUmaXghlPUFg0MjV0VURVbmc/view?usp=sharing