Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th October 2015, 10:18   #1  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Encoding slowdown

Is there anything a mere mortal can do to trackdown the cause of a slowdown?

I've been re-encoding a bunch of AVIs I first remuxed as MKV (old TV captures) and every so often I notice one will run at half the usual speed. I'm pretty sure it doesn't slow down. It starts off slow and stays slow. As I'm using slow filtering I'm encoding them two at a time, but I've noticed the same thing happen when only running one encode. If I stop the "slow" encode and start it again, it invariably runs at normal speed. I've only noticed it happen when using QTGMC and LSFMod in the same script. Is there any way to determine if it's a plugin at fault or if it's some odd Avisynth bug? I'm running (sorry) XP and Avisynth 2.6.0.6

I've had odd problems before when combining QTGMC and LSFMod. One batch of files would often encode at half speed if I encoded them from the beginning, but simply putting something like Trim(50,0) at the end of the script would ensure the encoding would run at normal speed. I just don't know if it's possible, or how to find the culprit. Here's today's example:

Same type of source video. The one on the left is running at normal speed, while the one on the right is running at half speed.


After aborting the encode on the right and starting it again, it runs at normal speed.


After aborting it a second time and adding Trim to the script so it commences from where it left off the first time, it still runs at normal speed.


This is the script:
Quote:
LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.mkv.ffindex", fpsnum=24000, fpsden=1001, threads=1)
QTGMC(InputType=1, Ezdenoise=2)
LSFMod(strength=66)
gradfun3()
The resolution of these files is only 640x480. When this problem occurs while re-encoding HD video, which it does now and then, things get really slow.
Thanks.

Last edited by hello_hello; 13th October 2015 at 10:24.
hello_hello is offline   Reply With Quote
Old 13th October 2015, 12:02   #2  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Hello, Hello Hello.

Sorry dont have a clue about cause of your problem, however

Quote:
putting something like Trim(50,0) at the end of the script would ensure the encoding would run at normal speed
I pretty much always put a Trim(0,0) in my automated scripts to make sure that any spliced clips dont result in audio sync problems,
all it does is chop off any extra audio that is longer than video, OR, pad (EDIT: with silence) short audio to same length as video.
Might be worth a try seeing if Trim(0,0) at end of your scripts obviates or 'hides' the problem that you are having.
There should be no ill effects.
Good luck.

EDIT: Adding a trim to end of script would insert an extra cache, but no idea why that might prevent the problem.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 13th October 2015 at 17:17.
StainlessS is offline   Reply With Quote
Old 13th October 2015, 16:11   #3  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,691
I don't know of tools or methods to help track down the cause of a slowdown. However, the symptoms you describe can be caused by running out of RAM memory, and the system then switching over to using your disk drive as "virtual memory." This results in a condition known as "thrashing." The next time you do an encode, look at the disk drive light on your computer at the beginning of the encode, when everything is running fast. Then, if you sense a slowdown, look at the disk drive light again and see if it is lit all the time, or is lit a lot more than before. If so, you've got thrashing, and this is most likely your problem. Most AVISynth encodes are not disk bound, and usually the disk light is off more than on.

If you do suspect disk thrashing, a way to sometimes get around memory issues -- although it is not a fix that will always work -- is to use a "SetMemoryMax()" statement at the beginning of the script. The largest number you can use depends on what version of Windows you use. The number is given in kB, so a good number to start with is 768, e.g., SetMemoryMax(768).
johnmeyer is offline   Reply With Quote
Old 13th October 2015, 16:18   #4  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 476
Don't know if it's the same problem, but i had the same symptoms and solution with QTGMC using LSMASH (half-speed encodes solved by trimming off the first few frames.) Something about it would cause LSMASH to keep creating and killing threads.

http://forum.doom9.org/showthread.ph...58#post1736158

Though it will occasionally do it without QTGMC, it seems to be a major trigger.

Set Threads=2 and load up process explorer (with admin access) and see if ffms2 is doing the same thing.
If it is the same bug, your half-speed encodes may have errors.

Last edited by kuchikirukia; 13th October 2015 at 16:33.
kuchikirukia is offline   Reply With Quote
Old 16th October 2015, 08:48   #5  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Thanks for the replies guys.

I had a very repeatable QTGMC speed issue at one stage with particular files (but once again, only in combination with LSFMod). I posted about it here, and at VideoHelp, along with a sample of the video in question. That's when Trim(50,0) stopped the slowdown from happening. In that case, so did using MP_Pipeline. I also discovered if I reverted back to an earlier version of QTGMC the problem went away. Dogway also modified his mod of QTGMC for me and that fixed the problem, but I don't think it was ever discovered why.
In that case MP_Pipeline preventing the slowdown seemed to point to a memory issue, but if it was, it makes no sense that something as simple as Trim(50,0) could fix it too, or switching to an older QTGMC version would do likewise.
I'm pretty sure it happened whether I was using ffms or L-Smash for indexing, but I might need to re-test that.

In the above case the problem was 100% repeatable for me, and re-starting the encodes didn't make the problem go away, whereas the files I referred to in the opening post here generally encode at normal speed, only every now and then one doesn't, despite the source files all being the same (640x480, Xvid AVIs). That makes it even harder to track down the cause, because it's so irregular and random.

I don't think it's a memory issue, because it's happened while the PC's been unattended and MeGUI is running through the jobs in the queue two at a time, yet job number 14 (for example) might encode at half speed for no apparent reason, then it's back to full speed for the next job. If it is a memory issue, I've not noticed any disc thrashing as a result. The hard drive light just flashes now and then.
I've not seen any errors in the slow encodes either. I checked one quite thoroughly and it looked fine, even though in that case encoding had slowed to about 1fps.

I'll probably try the sample I linked to again in the next day or so (if anyone else would care to try it, it's attached to the VideoHelp post I linked to along with the scripts I was using) as "hopefully" that'll make the problem 100% repeatable again, and if so I'll try Trim(0,0) to see if that makes a difference. I'd be interested to learn if the sample encodes at normal speed using the same script for someone else (it encoded at a snail's pace using two different PCs here).

Thanks.

Last edited by hello_hello; 16th October 2015 at 08:59.
hello_hello is offline   Reply With Quote
Old 20th October 2015, 08:03   #6  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
I think maybe I'll try older versions of QTGMC next time to see if that's the problem. The main reason it's so noticeable for me is I generally run a bunch of encodes with similar scripts one after the other, and often two at a time.

This encode started while I was in bed. Along with a second encode which started around the same time. I was fairly surprised they hadn't completed when I checked. They both ran at the same speed. The pertinent info from MeGUI's log file:

Quote:
[Information] [20/10/15 9:35:04 AM] Avisynth input script
-[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
-[NoImage] DGDecode_mpeg2source("D:\078 Genesis Of The Daleks, Part 4.d2v")
-[NoImage] trim(0,712).TFM().ChangeFPS(50,1)\
-[NoImage] ++trim(713,34273).QTGMC(sharpness=0.5)\
-[NoImage] ++trim(34274,0).TFM().ChangeFPS(50,1)
-[NoImage] crop(22, 10, -24, -12)
-[NoImage] Spline36Resize(640,480,0,1,0,0)
-[NoImage] gradfun3()
[Information] [20/10/15 9:35:04 AM] Job command line: "C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset slow --tune film --crf 18.0 --keyint 500 --vbv-bufsize 78125 --vbv-maxrate 62500 --no-fast-pskip --stitchable --colormatrix bt470bg --sar 1:1 --output "D:\078 Genesis Of The Daleks, Part 4.mkv" "D:\078 Genesis Of The Daleks, Part 4.avs"
[Information] [20/10/15 3:55:18 PM] encoded 71102 frames, 3.12 fps, 1606.01 kb/s
Yet the two encodes currently running use this same script, the same encoder settings, with only a slight difference in frame numbers for Trim(), they're both currently 20% complete and both plodding along at 6.9fps. It seems odd that whenever an encode runs slower than it should, it's always around half the speed that it should.

Quote:
[Information] [20/10/15 5:17:03 PM] Avisynth input script
-[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
-[NoImage] DGDecode_mpeg2source("D:\078 Genesis Of The Daleks, Part 6.d2v")
-[NoImage] trim(0,733).TFM().ChangeFPS(50,1)\
-[NoImage] ++trim(734,34040).QTGMC(sharpness=0.5)\
-[NoImage] ++trim(34041,0).TFM().ChangeFPS(50,1)
-[NoImage] crop(16, 6, -16, -6)
-[NoImage] Spline36Resize(640,480)
-[NoImage] gradfun3()
hello_hello is offline   Reply With Quote
Old 21st October 2015, 01:01   #7  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
It's possibly something to do with Trim(). I had two more encodes running simultaneously today and both had two "layers" of Trim() in the script. When I checked, both were running at about one quarter speed rather than the usual half speed. About 1.7fps.

Quote:
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\video.d2v")
AssumeTFF()
trim(0,733).TFM().ChangeFPS(50,1)\
++trim(734,34040).QTGMC(sharpness=0.5)\
++trim(34041,0).TFM().ChangeFPS(50,1)
crop(16, 6, -16, -6)
Spline36Resize(640,480)
gradfun3()
Trim(0,68079)\
++Trim(68081,68081)\
++Trim(68081,0)
I aborted both encodes, changed the second lot of trims so they resumed encoding where they left off (about 7 minutes from the beginning), restarted both and now they're plodding along at 6.53fps and 6.60fps respectively. It's a mystery.....
hello_hello is offline   Reply With Quote
Old 21st October 2015, 02:14   #8  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 476
Using your sample with L-SMASH and QTGMC 3.33 I get a lot of MSVCR120 thread destruction/creation causing slowdowns, though it has a period different from what I observed in my encodes (instead of constant Christmas-tree flashing slowing it to half, it does it for a few seconds, then is good for a few seconds.)
Note this is without avstp.dll, which I had disabled for other reasons, though I checked and it does it with.



Trim(50,0) and it's clear sailing:



Though your problem was using FFMS2, and I'm not seeing any slowdowns with that. (E: note, I wasn't looking at it from the very start of the clip here. See further down where there is a problem with 3.33 and FFMS2 in the first 150 frames)



E: QTGMC 3.33d, though! Halfway through the encode FFMS2 goes crazy with CPU usage and we slow down significantly.


This is with your
Code:
QTGMC(InputType=1, Preset="medium", EzDenoise=1)

crop(4, 2, -4, -2)
Spline36Resize(1280,720)

LSFMod(strength=75)
We have a few FFMS2 CPU spikes early in the encode, it settles down to ~0.2-0.4% CPU util per thread (where it should be), but around 50% complete it jumps to 2%-6% on each thread and the avs4x264mod thread drops to 4-6% from 12.3%.
Since I have a hyperthreaded quad-core and there was plenty of CPU left, simply having extra CPU util on the FFMS2 threads should not have slowed avs4x264mod down. My guess is it wasn't being fed.
E2: Still does it adding setmemorymax(1200)

E3: Trim(0,0) doesn't help
E4: Trim(1,0) doesn't help

E5: Trim(50,0), and we're good (though we already knew that)
Trim(10,0) is good
Trim(3,0) is good
Trim(2,0) is good
Trim(1,0) (again) bad.
Edit (many moons later): Trim (2,0) was good there, but not always. Just did another round of tests where it took Trim (4,0) for it to settle down.

With Trim(2,0) or greater, FFMS2 is 0.2-0.4% CPU util throughout. With Trim (1,0) or lower, it's high at 1.2% to start, then goes up and down from 0.2 to 5% for a bit before settling at the 0.2-0.4% level, until hitting a spike at 48% of the way through, then pretty much shitting itself at 51%, which it never recovers from.

E6: QTGMC 3.33 without Trim seems to have problems at the start, too. It just doesn't result into it faltering later.
Without trim, the FFMS2 threads are at 1.4% util from the start, dropping down, then spiking to 3% at frame 20, 4% at frame 30, 6% at frame 60. Pretty much settles down after frame 80 except for a spike around 150.
Add Trim(2,0) and it's clean all the way through.

E7: Switching to LSMASH, those frames correspond where it creates and destroys MSVCR120 threads.

E8: And with 3.33d and LSMASH, 55% is where we go full Christmas with thread creation/destruction. Craps out all the way to the end.
FFMS2 has a solid event at 52-53% of 5-6% cpu util that doesn't seem to correspond to anything in LSMASH. From 53% until 55% it's back to 0.2%, and 55% is where it craps out and never recovers.

And for anyone wondering, QTGMC 3.32 also seems to have those initial problems with the first 150 or so frames. Trim(2,0) clears it up.

Even though it takes LSFmod to make 3.33d crap out at 55% here, I have definitely had QTGMC crap out without LSFmod.

Oh: System is Windows 10; Groucho2004's Avisynth 2.6.0.6 ICL10
Same result with regular 2.6.0.6
Same with Avisynth+.
Trim (2,0) seems to fix it with all.
So I'd say QTGMC 3.33d is busted. 3.33 and 3.32 don't seem to destabilize like 3.33d here, but since they also exhibit some problems at the start, it might be possible that a different script will cause them to crap out at some point too.

Ran another test with 3.33d, this time bobbing with:
Code:
QTGMC()
LSFMod(strength=75)
It craps out at 24%.
So it doesn't seem to be related to anything with a feature of the clip, it's number of frames processed.
Inputtype=1 craps out after around 350 output frames
bobbing craps out after around 350 output frames
Bob with selecteven() and it craps out after around 170 output frames.
And I'm done.

Last edited by kuchikirukia; 16th March 2016 at 08:50.
kuchikirukia is offline   Reply With Quote
Old 22nd October 2015, 11:39   #9  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Wow.... thanks for all the testing. I only just saw your post and while I've read it, I probably haven't taken it all in properly yet. I'm probably going to have to come back to this later tonight or tomorrow.

After several more half speed encodes today (while encoding scripts two at a time using this PC and also while encoding them one at a time using another PC) I switched back to the QTGMC version dogway modified for me and so far it's been fine. Yesterdays problem encodes used DGDecode for decoding so I'm assuming it's not caused by the decoder as such. Dogway's script download link no longer works, but I've posted here asking if he could apply the same mod to the latest QTGMC (3.33s) so I could test it (I'm not sure I trust myself to modify QTGMC correctly). If you feel so inclined, could you try again with the attached version of QTGMC. It's 3.33d with "revert to QTGMC_deflate/QTGMC_inflate" applied and I strongly suspect that's got something to do with it. I think 3.33d was the first version to use mt_xxflate.

So far I've been able to confirm that when encoding slows down, CPU usage also drops. When I'm running two normal speed encodes simultaneously using this PC, CPU usage sits on 100%. When two simultaneous encodes are both running at half speed for no apparent reason, CPU usage is more like 60%.

Anyway, thank you very much for your time and testing. Hopefully I might be able to post something more substantial than "QTGMC is sometimes slow" in the QTGMC thread soon so someone can have a look at fixing it. There's two versions of QTGMC included in the following link.

"QTGMC-3.33d (mod) v2.avsi" is version 3.33d with "revert to QTGMC_deflate/QTGMC_inflate" and so far today it's been fine.
"QTGMC 3.33s (mod) v2.avsi" is the version I've been using lately and the one resulting in slowdowns over the last few days. It should be the same as the version labelled 2015 9 10 here. I renamed the avsi files to stop myself becoming too confused over which flavour I was using.

Thanks.

Same zip file, two different links (in case one doesn't work).
http://www.filedropper.com/qtgmc-333d333s
http://www.megafileupload.com/9y7z/Q...3d_&_3.33s.zip

I'll return later to read your previous post again.... more thoroughly.

Last edited by hello_hello; 22nd October 2015 at 12:09.
hello_hello is offline   Reply With Quote
Old 22nd October 2015, 15:22   #10  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
kuchikirukia,
I still can't experiment too much yet as I'm wanting to finish the encoding jobs in the queue first, but since switching to the version of QTGMC 3.33d dogway modified for me, neither PC has missed a beat. Both CPUs are running close to 100% and encoding is running at normal speed for these jobs (I know that because they're consistently running at about twice the speed of some identical encodes jobs this afternoon). I'm using QTGMC and LSFMod in these scripts and that still hasn't caused a slowdown with the modified QTGMC.

I tried having a play with Process Explorer, but aside from the fact I've never used it before, I don't seem to be seeing the same info as you. I've not using avs4x264mod so I can only look at x264.exe but i'm not seeing any Avisynth related processes. I don't know if that's normal, or because I don't know what I'm doing, or because I'm using XP (I've put a parts list together for a new PC build and plan on a trip to the local PC shop tomorrow, but it's still XP until next week).

I am curious about one thing though. I thought maybe my not seeing Avisynth related processes might have something to do with avstp.dll. It probably doesn't, but what do I know, so I removed it from the Avisynth plugins folder and started a fresh encode. It still appeared in the threads list. So I thought maybe Avisynth kept it loaded between encodes, if that's even possible, so I rebooted and tried again. It still appeared in the threads list. When I removed QTGMC from the script, it didn't. How can QTGMC appear to be causing a plugin to auto-load when the plugin isn't in the plugins folder? Is it normal? Thanks.



Edit: Okay I found a partial answer. When I move avstp.dll to the root of my D drive it still manages to get loaded/used. I'm not sure why and it's not what I expected. I tried the root of the C drive and the E drive and it's not loaded from there, but the root of the D drive and it is. I assume that's not inexplicable, but I don't know what the explanation is.

Cheers.

Last edited by hello_hello; 22nd October 2015 at 15:29.
hello_hello is offline   Reply With Quote
Old 22nd October 2015, 20:29   #11  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 476
You have another copy of avstp.dll in some auto-load directory.

Ok, while testing yours just found out that just:
QTGMC(inputtype=1) [and thus preset="slower]
...makes them all crap out from beginning to end. (including 3.32) LSFMod not needed. Trim doesn't fix it. This is a super-duper crap-out not seen before.
Add preset=medium to it and we're good with 3.32. (haven't tested the others)

I'm also now noticing some hiccups with just using QTGMC() using 3.32. Past 25% we definitely have a lot of 2-5% CPU util on FFMS2, and it does slow down a bit, but just not half. Goes from 2.83fps (and rising) to 2.45. This is with just assumetff() and qtgmc() -- nothing else.
Rising indeed: with Trim(50,0) it tops out at 3.1 fps.

This problem doesn't seem to affect it at the preset=slow level. 5.83fps with or without trim. (though a heavier script might)

I'll run a couple tests with your scripts in the next post. Just gonna leave this with 3.32 since it's more important.

Last edited by kuchikirukia; 23rd October 2015 at 00:52.
kuchikirukia is offline   Reply With Quote
Old 22nd October 2015, 20:59   #12  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 476
Your 3.33s mod v2 breaks at 350 frames with QTGMC(preset="slow")
3.33d mod v2 doesn't.
At preset= slower, 3.33d mod v2 does the same thing as 3.32 though. It slows down around 250 frames in.
Trim (50,0) fixes it.
kuchikirukia is offline   Reply With Quote
Old 22nd October 2015, 23:54   #13  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
hello_hello change nothing but the below



anyway I made it

http://forum.doom9.org/showpost.php?...postcount=2041

2016 one
__________________
See My Avisynth Stuff

Last edited by real.finder; 19th January 2016 at 04:22.
real.finder is offline   Reply With Quote
Old 23rd October 2015, 00:35   #14  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 476
Ok, that 3.33s just posted reverts to the previous (3.32, 3.33,"3.33d mod v2") behavior: with a call of QTGMC() it slows down after ~300 frames. Though not halving. With FFMS2 showing excessive CPU util:



Without trim: 2.53 fps
With trim(50,0): 3.10 fps

Last edited by kuchikirukia; 23rd October 2015 at 00:53.
kuchikirukia is offline   Reply With Quote
Old 23rd October 2015, 07:37   #15  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by kuchikirukia View Post
You have another copy of avstp.dll in some auto-load directory.
Because I'm using Avisynth 2.6.0.6 there's only one auto-load directory in the registry.
I did a thorough search though, and there's no avstp.dll in a directory that could be an auto-load directory, plus it only loads when I put it at the root of the D drive. If I put it on another drive it doesn't load (unless it's in the avisynth plugins folder).

I even searched the registry for "PluginDir2_5" and only found one instance, pointing to the usual Avisynth/plugins folder. I'll try again later with some other plugins to see if they all autoload when residing at the root of the D drive, or if avstp.dll is the only one. I'm certain it is loading from there, unless I've lost my mind.

All my current jobs finished without any slowdowns, so I'll give the modified 3.33s a spin shortly with the problem sample (thanks real.finder), although I don't expect the result to be any different to yours kuchikirukia.

One thing I'd be keen to learn, is why that sample? What's different about it that it always causes issues with QTGMC?

Last edited by hello_hello; 23rd October 2015 at 07:39.
hello_hello is offline   Reply With Quote
Old 23rd October 2015, 08:44   #16  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
So far the new QTGMC mod is behaving itself with that sample for me. Even when using preset="slow".

Have I mentioned that for this sample at least (and for me), the other fix, aside from Trim(50,0) was to use MP_Pipeline? It fixed the problem for these particular encodes, but I'm fairly sure there's been a few encodes since where it didn't. Why MP_Pipeline changes things in relation to slowdowns, I have no idea.

I'm copying the numbers from MeGUI's log file, and keep in mind this PC's old so it's slow. I've listed the encoding speed for comparing QTGMC versions.

QTGMC 3.33s (new version) - 3.89fps.
QTGMC 3.33s with Preset="slow" - 3.11fps
QTGMC 3.33s with MP_Pipeline - 4.66fps

QTGMC 3.33d (original version) - around 1fps (I didn't bother running the whole encode)
QTGMC 3.33d with Preset="slow" - around 1fps (I didn't bother running the whole encode)
QTGMC 3.33d with MP_Pipeline - 4.69fps

I'd use MP_Pipeline all the time for HD (with QTGMC and LSFMod), but as I'm still using XP and I tend to run two QTGMC encodes simultaneously, I think I run out of RAM when encoding two at a time because eventually encoding speed slows to a crawl. The individual encodes tend to be a little slower without it, but they run at "normal" speed from start to finish.

kuchikirukia,
I assume I'm not able to see as much info about the various processes as you because I'm running XP? I can't tell what ffms2 is doing. I'm pretty sure I tried using L-Smash instead at the time (for these samples) with no change, but are you using the exact script I posted at VideoHelp for testing? I ask, because I'm using an older version of ffmsindex as it tends to behave itself, but now and then ffmsindex does odd things due to the frame rate conversion MeGUI adds to the script. Mostly I think it's a good idea to include it, but now and then it makes fmsindex behave oddly (it tends to drop/repeat frames when the source is AVI). I mention it in case that's your ffms2 issue. I'm using version 2.21, I think. ffmsindex.exe is dated 21st June 2014.
Quote:
MP_Pipeline("""
LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\test.mkv", cachefile="D:\test.mkv.ffindex", fpsnum=24, fpsden=1, threads=1)
QTGMC(InputType=1, Preset="medium", EzDenoise=1)
### prefetch: 16, 0
### ###
""")
crop(4, 2, -4, -2)
Spline36Resize(1280,720)
LSFMod(strength=75)
gradfun3()

Last edited by hello_hello; 23rd October 2015 at 08:46.
hello_hello is offline   Reply With Quote
Old 23rd October 2015, 08:55   #17  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by hello_hello View Post
Because I'm using Avisynth 2.6.0.6 there's only one auto-load directory in the registry.
I did a thorough search though, and there's no avstp.dll in a directory that could be an auto-load directory, plus it only loads when I put it at the root of the D drive. If I put it on another drive it doesn't load (unless it's in the avisynth plugins folder).
Avstp.dll gets automatically loaded if it's in:
- a Avisynth autoload directory
- the directory where the script resides
- a directory to which the "PATH" environment variable points

If, for example, you or some program you installed added "d:\" to the "PATH" variable, it will be loaded.
I suggest you check that and also run the AVS Info Tool, saving the main and plugin info logs and post them here (pastebin).
Groucho2004 is offline   Reply With Quote
Old 23rd October 2015, 09:46   #18  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 476
You need to use threads=2 for it to split the FFMS2 and LSMASH threads out for you to see in process explorer.
kuchikirukia is offline   Reply With Quote
Old 23rd October 2015, 09:55   #19  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by hello_hello View Post
Have I mentioned that for this sample at least (and for me), the other fix, aside from Trim(50,0) was to use MP_Pipeline? It fixed the problem for these particular encodes
I don't use MeGUI but as I see it use avs4x264mod, maybe it has some issues with this case

using MP_Pipeline will do something like avs4x264mod but between script blocks
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 23rd October 2015, 11:48   #20  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by real.finder View Post
I don't use MeGUI but as I see it use avs4x264mod, maybe it has some issues with this case

using MP_Pipeline will do something like avs4x264mod but between script blocks
MeGUI only uses avs4x264mod when the 64 bit version of x264 is being used, but in my case I can't because I'm still running 32 bit XP (just for one more week, hopefully).

I checked the command line and there's definitely no avs4x264mod involved.

[Information] [23/10/15 6:21:24 PM] Job command line: "C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset slow --tune film --crf 18.0 --keyint 240 --vbv-bufsize 50000 --vbv-maxrate 50000 --stitchable --colormatrix bt470bg --sar 1:1 --output "D:\test.mkv.mkv" "D:\test.mkv.avs"
hello_hello is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.