Avisynth 2.6 MT

[SEt]

Current version 2015.02.20: https://www.dropbox.com/s/dckxoowjlzwku1s/avisynth_20150220.7z

Previous version 2013.09.28: https://www.dropbox.com/s/6f56nvqvxrde22q/avisynth_20130928.7z


Note: Starting from version 2012.04.03 plugin's folder is searched first for its dll dependences. You can now move some things from system32 folder to plugins folder, but check that there are no unexpected old dll versions in plugins folder in case you see strange errors.

Here is my builds of Avisynth 2.6 with several (mostly MT) fixes. MT mode stability is way better than Avisynth 2.5.8, general stability - the same as official Avisynth 2.6 (which is again better than 2.5.8 due to many bugfixes since then).

How to use it correctly

1. Installation
Install any recent official version of Avisynth.
Replace avisynth.dll in your system32 (on 32-bit OS) or syswow64 (on 64-bit OS) folder with the one from this thread.

2. Usage in scripts
Understanding different MT modes would help a lot, but most things are going to work ok with script like this one:

SetMemoryMax(512)
SetMTMode(3)
source_filter()
SetMTMode(2)
processing_filters()

If you are using it with ffdshow for realtime processing - at the very end add
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

and ensure you have "Buffer back/ahead" enabled with enough number for "ahead" ("back" usually can be 0 with no problems). Use 1-2 more than it sets with "Use Current" button while playback is running.
Note: current ffdshow has bug in interaction with avisynth that results in often crashes on stop of MT scripts. It does not affect playback itself.

3. In case something crashes or works wrong
Avisynth is desinged in such a way that part of it is compiled into each plugin. That means if you experience crashes first of all you should check that all used plugins are built with recent headers as old ones are not compatible with multithreading.

The other thing is memory usage. Being 32-bit Avisynth has certain memory limits.
On 32-bit OS: you are likely limited to 2GB per process. With /3GB windows boot option it can be increased to 3GB but it's not problem free.
On 64-bit OS: it's 4GB per 32-bit application, so there are benefits of using 64-bit OS even if 32-bit applications are all you need.
Note: exe file of application must be correctly compiled to use mentioned above 3GB or 4GB. Not an avisynth or its plugins problem, but worth noting.

If you see (in Task Manager) that application crashes with memory usage near 2/3/4 GB (depending on your environment) - you are facing cache inefficiency of MT Avisynth. Try increasing or decreasing SetMemoryMax, fewer number of threads (second parameter in first SetMTMode). No guaranteed results here.

Plugins/scripts that depend on sequential frame requests are not going to work correctly with current MT mode. Not really MT problem, as they also won't work correctly in non-MT mode when frame requests from next filter are not sequential.

If you are sure mentioned above 3 cases don't apply to your crash/wrong result - post here a way to reproduce it.

4. Short guide to SetMTMode
SetMTMode is the command that switches Avisynth into MT mode. Without it MT Avisynth works like the usual one.
Useful MT modes:
1 - one filter instance per call in script, no guarding from Avisynth, only for filters that are designed for this mode, like distributor().
3 - one filter instance per call in script, Avisynth guards requests for output. The mode to use with source filters. (Mode 5 will do for them too, but is overkill and should be avoided.)
2 - each call in script produces N (number of threads) instances of filter. Use for the rest.

When using MT mode with filters that have ability to spawn several internal processing threads - be sure to set such filters to use only 1 thread. Otherwise for example with 8-thread system MT mode will spawn 8 threads with once instance of such filter per thread (in MT mode 2), each filter instance will spawn 8 threads. End result: 64 threads (ouch).


Older versions:
2013.03.09: https://www.dropbox.com/s/xhqggxamegia420/avisynth_20130309.7z
2013.02.20: https://www.dropbox.com/s/x58c1ofdvc31dxi/avisynth_20130220.7z
2012.08.28: http://www.mediafire.com/file/4dm34kc7tug7rrk/avisynth.7z
2012.05.16: http://www.mediafire.com/file/20gn1c2s45la14w/avisynth.7z
2012.04.03: http://www.mediafire.com/file/rlzn2kkrcad3j71/avisynth.7z
2012.03.31: http://www.mediafire.com/file/k9g67qbe6tyo8xa/avisynth.7z
2011.09.13: http://www.mediafire.com/file/3gd3851mb9o9wq7/avisynth.7z
2011.07.19: http://www.mediafire.com/file/9jk0cb9r56myduz/avisynth.7z
2011.07.14: http://www.mediafire.com/file/358wvsb4bngqjgi/avisynth.7z
2009.09.19: http://www.mediafire.com/file/2dz4y0wztzz/avisynth.7z
2009.08.15: http://www.mediafire.com/file/zjaelwemjii/avisynth_26.7z
2009.08.08: http://www.mediafire.com/file/hdvgzm5xdmn/avisynth_26.7z

[Keiyakusha]

Thanks. I've used Kemuri's build for some time and it works stable as last stable 2.5.8. I will try your build now.

Edit: Next time we'll see working avisynth 3.0 build from SEt, right? ;)

[Fizick]

SEt, it is interesting, but please be more respective to GPL

[SEt]

I hope you don't mean including gpl.txt everywhere. As for sources - i'm respective and you can get them if you ask. (Well, actually i asked Wilbert and waiting for cvs access now.)

[TheFluff]

but you have to make a written offer to provide the sources! and it must be valid for at least 3 years! you're gonna get sued!!111!

late irony edit: http://forum.doom9.org/showthread.php?t=32863

[10L23r]

Is mediafire dead or something?? I've been stuck at "Processing download request..." for about five minutes :(

[Fizick]

Here is download link to source code I have got from SEt


http://www.mediafire.com/file/mmlzutjueuv/AviSynth26.7z

Changes:
- MT related fixes.
- General code cleanup (for scope, const).
- Project splitted and settings cleaned up. Converting from VS6 is a great way to get strange settings.
- Converted .asm to yasm. If we ever hope to be portable - it'll most likely be yasm for assembler.


First external look: changes to current CVS are rather massive! IMHO they should not be committed at once. but by portions for more easy revision (tracking) of changes.

More comments later.

[IanB]

Yes, "changes to current CVS are rather massive!", there are a lot of "white" changes like adding "const" and "extern" declaration to things that probably should have had them from the beginning. Arbitrary changes like using "long long" for "__int64" and fiddling with the for loops are not transparent as VC6 (yes we still support that) do not support them. Getting the "interlocked*" logic in many places is relevant, I had already found a lot of these but it help to have independent review. The code in cacheMT.cpp is very out of date (circa 2.5.5) and does not conform to 2.5.8 expectations for a Cache:: module, medium term this module will be deleted and the code subsumed back into the main cache code, it was only ever a place holder while TSP worked on the code.

[Dark Shikari]

but you have to make a written offer to provide the sources! and it must be valid for at least 3 years! you're gonna get sued!!111!Or just include the source code with the binary... :rolleyes:

[lych_necross]

Dark Shikari is right. Just include the sources with the binary.

[SEt]

I think there is absolutely no reason for supporting VC6 compiler and flooding the code with
stupid compiler forgets to save ebx!!
Damn compiler does not correctly cast to intermediate results to float
and hacks to avoid it. Code should be moved towards standard C/C++ and maybe GCC compatibility. Of course supporting the VC6 build environment is perfectly fine.

Cache is the real problem - i'm getting bad memory leaks with heavy threading and trying to fix it now. Changes submitted are intermediate so it won't crash and disturb testing other things.

[TheFluff]

using "long long" for "__int64"

int64_t

e: isn't a major version bump a very good occasion to drop support for an ancient and buggy compiler anyway, I mean if you don't drop it now you'll still be sitting here supporting it in 2020 or so judging by how often avisynth gets major version bumps

[SEt]

Fixed minor threading bug and major memory leak:
--- avisynth.cpp 2009-08-08 22:20:34.550375000 +0400
+++ avisynth.cpp 2009-08-13 15:12:07.305375000 +0400
@@ -144,8 +144,9 @@
return &i->vf;
LinkedVideoFrame* result = (LinkedVideoFrame*)::operator new(sizeof(LinkedVideoFrame));
result->vf.refcount=1;
- result->next = g_Bin->g_VideoFrame_recycle_bin;
- result->next = (LinkedVideoFrame*)InterlockedExchangePointer((long*)&g_Bin->g_VideoFrame_recycle_bin,result);//g_VideoFrame_recycle_bin is assigned twice to result->next just in case another thread reads result->next before the last assignment
+ do
+ result->next = g_Bin->g_VideoFrame_recycle_bin;
+ while (InterlockedCompareExchangePointer((volatile PVOID*)&g_Bin->g_VideoFrame_recycle_bin, result, result->next) != result->next);
return &result->vf;
}

@@ -1639,7 +1640,7 @@
InterlockedIncrement(&i->sequence_number); // Signal to the cache that the vfb has been stolen
return i;
}
- if (i->GetDataSize() > size) {
+ if (c > Cache::PC_Nil && i->GetDataSize() > size) {
// Remember the smallest VFB that is bigger than our size
if ((j == 0) || (i->GetDataSize() < j->GetDataSize()))
{
@@ -1659,7 +1660,7 @@
if (!CacheHead) break; // cache state will not change in next loop iterations

// Plan C: Steal the oldest, smallest free buffer that is greater in size
- if (j && c > Cache::PC_Nil) {
+ if (j) {
++g_Mem_stats.PlanC;
InterlockedIncrement(&j->sequence_number); // Signal to the cache that the vfb has been stolen
return j;

[IanB]

@SEt,

Thanks, you must be psychic I noticed the 2nd issue while reading your other big change bundle. It is still not quite right. In the MT case CacheHead could be NUL because CacheMT doesn't implement the new poke cache stuff yet, so you exit the loop without actually using "the smallest VFB that is bigger than our size". that's the trouble with quickly retro fitting code from the main branch. ;)

As for the 1st bit with g_Bin yeah it's stuffed. I am not happy with that whole concept, so ..... :cool:

[SEt]

No, the behavior is intended - i don't like plan C and would rather disable it. In case of memory starvation this "memory leak" can be quite unpleasant and more dangerous than memory fragmentation that it tries to prevent.

Let's see what can happen after we give bigger buffer than required (and usually it'll be 2..4+x bigger):
1) Big buffer won't be required in future - we are wasting memory, bad.
2) Big buffer will be required before allocated smaller frame is freed - we'll likely have to allocate another big buffer, wasting memory again, bad.
3) Big buffer will be required after smaller frame is freed, but before another smaller frame uses it - good, but i'd say unlikely.

[Keiyakusha]

Sorry if this thread not suits for my question...

So here (http://www.petaimg.com/u95/819test.png) is my image.
Here is my script:
Imagesource("test.png")
Converttoyv24().SwapUV()
And here is what I see when I open it in VirtualDub:
http://www.petaimg.com/u143/96123.png

So the question is, why chroma is swapped so I need to add SwapUV()? Is this some bug in VDub? Because if I add Converttorgb() to the end of the script - chroma returns to its place...
But more importantly why I'm getting this "extra" chroma or whatever is that? Am I doing something wrong?

EDIT: I'm using SEt's build from 1st post.

[SEt]

Color format conversions are currently broken (at least their dynamically compiled part). Also note that i haven't rebuilt the dll with posted bugfixes yet.

[BigDid]

Hi SET,

Here is the 1st official release of Avisynth 2.6. The main pupose of this release is to confirm compatibility with version 2.5.8. For scripts using only 2.5.8 features the results should be identical.
...
The next release will contain Sh0dans latest FastWire updates and his SSE3+ code enhancements.
...
and
...
Time is precious so I am skipping the frills for expedience sake. I am also restricting my participation in this forum, don't feel offended if I appear to be ignoring you, I am applying self discipline and not responding to anybody ;) ( I am skimming the posts every few days for any active items). This way I actually have time to work on the code.
...

If I read IanB comments well, he will first focus on compatibility... so I believe MT in 2.6 is under the stack.

If true, it will be up to you (if you have time to do so) to update your 2.6MT build. Can it be expected?

I do not want to put pressure on any developper (IanB or you) just have a roadmap on what to expect or not.

:thanks:

Did

[a451guy451]

I wanted to just note briefly, that I was testing the above build for a while and it was unstable during transcodes on both quad and 8 core systems. I detailed it briefly in the above "AviSynth 2.6.0 Alpha1 [August 20th]" thread. Tested it exhaustively on a dual core though, and it was great; no issues. thanks for the continued work on it!

[SEt]

Of course build 2009.08.08 is unstable (at least due to described in patch bugs). As this thread still interest someone, i've added newer build with posted patch applied (nothing else changed) - it's way more stable, but be sure to set enough SetMemoryMax to avoid late crash due to address space fragmentation.

BigDid, i have several MT-related ideas to write, but i don't want to maintain my own version of avisynth 2.6 unrelated to official. I've asked for official trunk/stable svn repositories but there was no reaction yet.

[BigDid]

Hi,

Thanks for the update. I have tried it, but the colors problems are forbidding a regular usage.
That could be something to put on top of the stack :)

I have followed (but note always understood) the "main/single-threaded" 2.6 thread and have seen these exchanges.
I will not put pressure on either side but if I can be of any help for the MT side ;) let me know.

Did

[levi]

Hey guys, it seems my problem is related to my quad core CPU as I have exactly the same symptoms as mentioned here: http://forum.doom9.org/showthread.php?p=1319483#post1319483

Switched to several different SetMTmodes, but it eventually stalls (CPU use & fps in vdub drop to zero) It starts out fast though.

So I was going to try the other modes...


MTSource(""" MPEG2Source("D:\my.d2v") """)


but i get:
Avisynth open failure:
Script error: Invalid arguments to function "MTSource"

I checked the syntax a few times but I can't find the error

[Gavino]

I checked the syntax a few times but I can't find the error
The syntax looks right. Perhaps it can't find MPEG2Source.
Do you have DGDecode.dll in your plugins folder?

[levi]

Yes, dgdecode is in plugins - it works fine with
MPEG2Source("D:\my.d2v")

MTSource(""" AviSource("pass2.avi") """)
gives the same error, but works fine when used normally

MT 0.7 (includes modified avisynth 2.5.7.5) works fine

:<

[SEt]

There actually was one more threading fix i haven't bothered to post due to expected rewrite of cache/MTMode in 2.6 that should solve the problem with hanging. See the first post for the rebuilt dll.

--- cacheMT.cpp 2009-08-08 22:03:34.034750000 +0400
+++ cacheMT.cpp 2009-10-05 15:15:03.734375000 +0400
@@ -430,7 +430,9 @@
InterlockedDecrement(&e_generated_refcount[i->e_generated_index]);
++g_Cache_stats.vfb_found;
LockVFB(i, env); // BuildVideoFrame expect the VFB to be locked
+ EnterCriticalSection(&cs_cache);
PVideoFrame retval=BuildVideoFrame(i, n);
+ LeaveCriticalSection(&cs_cache);
InterlockedDecrement((long*)&retval->refcount);
return retval;
}

[a451guy451]

Thanks for posting the new build. I'm looking forward to playing with it on a 4 and 8 core machine today...

[levi]

I'm curious to hear your results. I did not see any improvements in the hangs / crashes.

[a451guy451]

I'm still running my first test on my 8-core. It's a really complicated script that usually gives me 3-4fps, and it's running 12-14fps with this new DLL. It's been rock solid for the last 2h 30min, and I have another hour to go. BUT, when I was using the previous build it would hang itself in less than 5 minutes. I expect this will complete just fine. After I finish the 8-core test, I'll hop onto my quad core box and see if I can duplicate the results (I see no reason why it would give me any problems).

Sorry you're not seeing any improvement though. I'm only using Setmtmode(2,0), so perhaps you should give that a try if you haven't already.

VERY promising though. Thanks again SEt!

[a451guy451]

8-core test complete, with no issues (yay). I'll try to post the results of my test on a quad core tomorrow.

[7ekno]

8-core test complete, with no issues (yay). I'll try to post the results of my test on a quad core tomorrow.

Was that with the link called "Version 2009.09.19" ?

If that's the case, I will retry it later too ...

7ek

[a451guy451]

Yes it was.

[a451guy451]

Quad core works as well. Really, almost as fast as the 8-core, but I think the explanation for that is that I'm hitting a bottleneck elsewhere in my system. Cool deal either way.

[levi]

set, does it matter which version of devil.dll is used?

[BigDid]

Color format conversions are currently broken (at least their dynamically compiled part). Also note that i haven't rebuilt the dll with posted bugfixes yet.
Hi,

The last 2.6-MT from SET is really stable for me, but I am still getting some horizontal colors bands; don't know if related to the above quote though?

I could try to pinpoint what script/filter does trigger these bands if interested...

Did

[SEt]

I can't say anything about devil.dll. And of course if you want something fixed you need to post a way how to reproduce the bug.

[BigDid]

... And of course if you want something fixed you need to post a way how to reproduce the bug.
Hi,

Here are the infos I can give you:

Having a mpegsouce or a directshowsource,

Source being this test movie:
http://www.mediafire.com/file/r2rnvnnn2y1/bride1.m2v
from this thread:
http://forum.doom9.org/showthread.php?p=1328915#post1328915

autocrop() gives some colors problems (patchs of blue and red plus a thin horizontal green line at the bottom) with a resulting resolution of 700*384

Crop(movie,0,46,0,-50) is OK

mt("DeGrainMedian(mode=5)") is Ok

lanczosresize(720,432) is ok (as is autocrop +lanczos)

BlindPP(cpu2="xxxxoo", quant=16) -deblocking- or
BlindPP(cpu2="ooooxx", quant=5) -deringing- gives a green horizontal thick line at the bottom quite similar to the one in the 2.6 thread:
http://forum.doom9.org/showthread.php?p=1337438#post1337438
Blindpp() being a separate use of the cpu function from dgdecode, this could be expected.

Complex scripts sharpening and/or denoising with or whitout MT are Ok:
lsfmod()or
*mt("""lsfmod(strength=150, soothe=true,keep=10,edgemode=1)""")
MCtemporaldenoise() or
*mt("""MCTemporalDenoise(settings="medium",sigma=20,sharp=true,strength=200,protect=true,flat=true)""")
Softsharpen() or
*mt("""softsharpen(preset="film", net=14,debrT=1,debr=0, flou=16,derin=0)""",2,4,splitvertical=true)

* are examples only; parameters may not be appropriate or only if associated with other filters.

So I hope that the solution(s) from the main 2.6 thread can apply here. If not, someone (not me) will have to ask an update of dgdecode().

[IanB]

@BigDid,

It ain'i rocket science put a SetPlanarLegacyAlignment (True) after the BlindPP() line and see if it hides the problem.

(Hint: Having looked at the code, just halving the pitch, as is done here, is going to cause this problem.)

[levi]

BigDid, how are you doing MT("...") syntax with 2.6? where did you get 2.6 MT.DLL? I only saw avisynth.dll in those 7zips set posted.

[BigDid]

@BigDid,

It ain'i rocket science put a SetPlanarLegacyAlignment (True) after the BlindPP() line and see if it hides the problem...
Hi IanB,

Works fine. As I use the deblock part of blind PP before denoising/sharpening and the dering part after, I have tested that 1 statement of "SetPlanarLegacyAlignment (True)" at the end of the script will work fine also.
Thanks alot, good to have some constructive answers in these difficult times.

BigDid, how are you doing MT("...") syntax with 2.6?
Same as you are. Some syntax works some do not.
Basics are on the wiki page:
http://avisynth.org/mediawiki/MT_support_page
summarizing the basic MT 0.7 thread:
http://forum.doom9.org/showthread.php?t=94996

You have to juggle with triple quotes, overlap and/or splitvertical. I have updated the complex scripts in the above post as examples.


where did you get 2.6 MT.DLL? I only saw avisynth.dll in those 7zips set posted.
Same as yours:
http://forum.doom9.org/showthread.php?p=1331510#post1331510
http://www.avisynth.org/tsp/MT_07.zip

[IanB]

...
Works fine. As I use the deblock part of blind PP before denoising/sharpening and the dering part after, I have tested that 1 statement of "SetPlanarLegacyAlignment (True)" at the end of the script will work fine also.
It is not really fine to put SetPlanarLegacyAlignment(True) at the end of the script. Doing so may force any SSE2 code to use the slower unaligned memory access code path for YV12 chroma planes or poorly written filters may even crash. It also only works for YV12.

For filters that make illegal assumptions about pitch you should put SetPlanarLegacyAlignment(False) right before the problem filters statement and SetPlanarLegacyAlignment(True) right after it. i.e.Mpeg2Source("fred.d2v, cpu=1) # Bad planar code!
SetPlanarLegacyAlignment(True) # Do slow legacy alignment
...
SetPlanarLegacyAlignment(False) # Restore fast alignment
BlindPP(cpu2="xxxxoo", quant=16) # Bad planar code!
SetPlanarLegacyAlignment(True) # Do slow legacy alignment
...

[Delerue]

Just to say that the last version worked flawlessly for me. I'm using MVTools with a MFlowFPS script and with SetMTMode enabled. Performance is great and no artifacts at all.

Thanks, SEt. ;)

[levi]

As you can see in the example link (you probably have to download the image in order to see it), there are some artifacts not present in the source that turn up in the xvid encode. Please let me know if you have any idea what's wrong. I have run into this a couple of times now with different sources...


SetMemoryMax(512)
SetMTmode(3,0)
mpeg2source("AE.d2v")
SetMTmode(2)
TomsMoComp(1,5,1)
crop(268,8,1404,1072)
LanczosResize(576,432)

Using:
http://members.optusnet.com.au/squid_80/xvid_encraw.zip

xvid_encraw.exe -max_key_interval 250 -vhqmode 4 -bvhq -progress 250 -imax 4 -pmax 7 -bmax 10 -qtype 0 -threads 3

Example:
http://www.mediafire.com/i/?zmmmzttzlmz

Source:
http://www.mediafire.com/?zllfwwinm4m

Encode:
http://www.mediafire.com/?zllfwwinm4m

[hxhxd]

@levilevi,
avisynth 2.6 has no mt feature. you should ask in SEt's thread.

[levi]

what & what? :p

This is set's thread & he has posted links to multi-threaded 2.6 in the first post.

[Lynx Pardinus]

In the past I have experienced the same artifacts when using TomsMoComp in MT Avisynth 2.57.

Try using a different deinterlacer or try moving the SetMTMode after the TomsMoComp.

[a451guy451]

This is a small bug, but Histogram() seems to be broken in this build (I'm using histogram("level") specifically). It still shows up, but the waveform is nearly black (you can actually see it a little, but just barely and it doesn't appear to be accurate). It's not a huge deal, because I can always use one of the Virtualdub filters. I just wanted to bring it up because I've used this build extensively now and it's the only issue I've come across.

[hxhxd]

what & what? :p

This is set's thread & he has posted links to multi-threaded 2.6 in the first post.

Oh, sorry, I've make a big mistake. :rolleyes:

[ChaosKing]

I think i found a bug in Blackmanresize().
The bug only occurs if I set the taps parameter in the resize function:


subtitle("blackmanresize(640,480,50)")
blackmanresize(640,480,50)
crop(0,0,-0,-400)

http://chaosking.de/zeugs/blackman.png
http://chaosking.de/zeugs/blackman10.png
http://chaosking.de/zeugs/blackman50.png

[Gavino]

I think i found a bug in Blackmanresize().
The bug only occurs if I set the taps parameter in the resize function:
...
blackmanresize(640,480,50)
The third parameter is src_left, not taps, so you are shifting the image.
Use blackmanresize(640,480,taps=50).

[ChaosKing]

hmm ok, but Mediawiki says:

Basic usage:
BlackmanResize(clip clip, int target_width, int target_height, int taps)

so shouldn't be the third parameter = the taps parameter in my case??

[Gavino]

I see what you mean - the documentation is misleading.

[Wilbert, can this be improved? Perhaps remove 'taps' from Basic usage for Blackman, Lanczos and Sinc?]

[Boulder]

Hi SEt,

have you seen this thread yet: http://forum.doom9.org/showthread.php?t=151248? There seems to be something in the MT Avisynth build that a recent x264 doesn't like.

[SEt]

Seems like it now requires manual call to distributor() as ffdshow. Try adding at the end of script the same
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

[Boulder]

Seems like it now requires manual call to distributor() as ffdshow. Try adding at the end of script the same
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : lastSeems to work, thanks :)

[Dark Shikari]

Do note that when the x264-side fix is committed, such a call will likely break things horribly.

[kemuri-_9]

we implemented the same call that is used in the vfw interface, script wise this comes out to

cur_mt_mode = GetMTMode(false)
(cur_mt_mode > 0 && cur_mt_mode < 5) ? Distributor() : last

[Adub]

So is it recommended to be using SET's build of Avisynth 2.6 Alpha when I want to use MT, or should I use the newer version of the official Avisynth 2.6 Alpha (090927) release?

[cweb]

So is it recommended to be using SET's build of Avisynth 2.6 Alpha when I want to use MT, or should I use the newer version of the official Avisynth 2.6 Alpha (090927) release?
The latter doesn't support MT while SET's build does...

[Adub]

Ah, I thought that 2.6 was going to incorporate MT anyways. Thanks for clearing everything up.

[kemuri-_9]

afaik the official alpha build release is just a partial merge of the 2.6 branch into the main branch (formerly 2.5.x).
not everything of 2.6 was merged in...

where as set's build is from the 2.6 branch itself so it contains all the features of 2.6

[cweb]

afaik the official alpha build release is just a partial merge of the 2.6 branch into the main branch (formerly 2.5.x).
not everything of 2.6 was merged in...

where as set's build is from the 2.6 branch itself so it contains all the features of 2.6
Yes I think that's why the official alpha doesn't support MT...

[Boulder]

SEt, I get unhandled win32 exception crashes with a recent ICL build of x264 (r1416) and your Avisynth 2.6 MT build. Your multithreaded Avisynth v2.5.8 seems to work fine.

This is the script I used:
SetMTMode(5)
MPEG2Source("1.d2v")
SetMTMode(2)
clip1=last.Trim(0,74268)
clip2=last.Trim(74269,0)
clip1 ++ clip2.YADIFMod(edeint=NNEDI2(clip2))
Crop(2,2,-6,-2,true)
MCTemporalDenoise(chroma=true,enhance=true,sigma=7)

MCTemporalDenoise (http://forum.doom9.org/showthread.php?t=139766)
http://kemuri9.net/dev/x264/x264_r1416_set.zip

[SEt]

Script itself works fine for me, but eats 2.7GB of memory (with 720x480 resolution and 8 threads) what your build of x264 can't provide.
Change in that x264_icl.exe (32-bit of course) byte at offset 0x106 from 0x03 to 0x23 and run it on 32-bit system with /3GB or any 64-bit system.

[Boulder]

Script itself works fine for me, but eats 2.7GB of memory (with 720x480 resolution and 8 threads) what your build of x264 can't provide.
Change in that x264_icl.exe (32-bit of course) byte at offset 0x106 from 0x03 to 0x23 and run it on 32-bit system with /3GB or any 64-bit system.

Could this be fixed by using a lower SetMemoryMax()? I think I have it automatically set at 384MB (I have 2GB of memory). When looking at Task Manager, the x264 process consumes 700-800MB of memory.

[SEt]

There is no good way to limit memory usage of MT cache in avisynth now other than using less threads.

[Chainmax]

So, usage still consists of putting MT v0.7's dll in the plugin folder and the replace windows\system32's avisynth.dll with this one, right? Also, is this:

LoadPlugin("X:\wherever\MT.dll")
**load other filters**

SetMTMode(5)
**load source**
SetMTMode(2)
**rest of the filterchain**

still a good way to use multithreading or are there more nuances to it in this newer version?

[levi]

You dont need to load the mt.dll unless you mt a specific function

otherwise just load your favorite flavor of the patched version of avisynth will enable setmtmode()

http://avisynth.org/mediawiki/MT

Only nuance I found is disabling hyperthreading gives better performance.

[boondoggle]

I get an error when i press any arrow key in AvsPmod i.e just look through movie for about 10 seconds then it gives this:

Traceback (most recent call last):
File "AvsP.pyo", line 5662, in OnMenuVideoNextFrame
File "AvsP.pyo", line 9191, in ShowVideoOffset
File "AvsP.pyo", line 8950, in ShowVideoFrame
File "AvsP.pyo", line 9499, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception code 0xe06d7363

No filters just AVISource(clip). Any ideas?

[boondoggle]

Oh, and it appears only with your version of avisynth of course. Its quite annoying having to choose between about 40% speed increase or being able to edit scripts meanwhile processing :/

[Bob Wya]

Hi

Stupid question... But please, please can we have access to the .avs script name in the Avisynth 2.6 API (so it is available to externally linked filters)!! It's been in reasonably high demand (as a feature) and surely it's just a 5 line function/public class method... I spent hours looking through the main Avisynth 2.58 source for a way to access the avs filename for a filter I am currently working on... :mad:

:thanks:
Bob

[kemuri-_9]

there is no guarantee that an avs script was even used, so how are you expecting to handle that situation?

[Bob Wya]

there is no guarantee that an avs script was even used, so how are you expecting to handle that situation?

It is only a problem if you expose the API to Avisynth users!! I am talking about allowing filter developers access to this new function in their own filter classes (via the Avisynth.h header). Obviously if no Avisynth script is being used just do something sensible and return a null string "" or similar (pretty obvious I would of thought).

Bob

[Gavino]

Obviously if no Avisynth script is being used just do something sensible and return a null string "" or similar
As well as in the case where no script is being used (eg a program using the API via the library interface), it would also have to return a null value if called at run-time (GetFrame), since the script filename is a compile-time concept and the information is not present in the compiled filter graph.

[Bob Wya]

As well as in the case where no script is being used (eg a program using the API via the library interface), it would also have to return a null value if called at run-time (GetFrame), since the script filename is a compile-time concept and the information is not present in the compiled filter graph.

In my filter I need the name of the .avs script at the filter constructor stage - when it should be available (- right?)

The script name can be saved in a class variable in the filter constructor to use later on (e.g. in GetFrame()) anyway I guess.

Bob

[IanB]

From the current CVS :- global_var_table->Set("$ScriptName$", AVSValue());
global_var_table->Set("$ScriptFile$", AVSValue());
global_var_table->Set("$ScriptDir$", AVSValue());
{ "ScriptName", "", ScriptName },
{ "ScriptFile", "", ScriptFile },
{ "ScriptDir", "", ScriptDir },
...
HANDLE h = ::CreateFile(full_path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
if (h == INVALID_HANDLE_VALUE)
env->ThrowError("Import: couldn't open \"%s\"", full_path);

env->SetGlobalVar("$ScriptName$", env->SaveString(script_name));
env->SetGlobalVar("$ScriptFile$", env->SaveString(file_part));

*file_part = 0;
CWDChanger change_cwd(full_path);

env->SetGlobalVar("$ScriptDir$", env->SaveString(full_path));

DWORD size = GetFileSize(h, NULL);
DynamicCharBuffer buf(size+1);
BOOL status = ReadFile(h, buf, size, &size, NULL);
CloseHandle(h);
if (!status)
env->ThrowError("Import: unable to read \"%s\"", script_name);
...
AVSValue ScriptName(AVSValue args, void*, IScriptEnvironment* env) { return GetVar(env, "$ScriptName$"); }
AVSValue ScriptFile(AVSValue args, void*, IScriptEnvironment* env) { return GetVar(env, "$ScriptFile$"); }
AVSValue ScriptDir (AVSValue args, void*, IScriptEnvironment* env) { return GetVar(env, "$ScriptDir$" ); }
ScriptName is the raw input string to Import.
ScriptFile is the filename part of the parsed full pathname of the script file.
ScriptDir is the directory part of the parsed full pathname of the script file.

[Gavino]

From the current CVS :-
...
env->SetGlobalVar("$ScriptName$", env->SaveString(script_name));
env->SetGlobalVar("$ScriptFile$", env->SaveString(file_part));

*file_part = 0;
CWDChanger change_cwd(full_path);

env->SetGlobalVar("$ScriptDir$", env->SaveString(full_path));
...

Is that the only place the variables get set?
To allow for the nested nature of Imports, I would expect to see them being saved on entry to function Import and restored on exit.
(This would also reset them to null for the run-time phase.)

[Bob Wya]

ScriptName is the raw input string to Import.
ScriptFile is the filename part of the parsed full pathname of the script file.
ScriptDir is the directory part of the parsed full pathname of the script file.

Ah thanks for getting back to me! I thought I had read it was going to get added in to a new build of Avisynth. It might seem lazy that I haven't downloaded the 2.6 source code to check this... I'm just suffering brain burnout from trying to understand how the 2.58 code hangs together!!

:thanks:
Bob

[IanB]

Is that the only place the variables get set?
To allow for the nested nature of Imports, I would expect to see them being saved on entry to function Import and restored on exit.
(This would also reset them to null for the run-time phase.SourceForge.net > Find Software > avisynth2 > SCM Repositories > avisynth2 > avisynth > src > core > parser > script.cpp (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/parser/script.cpp?r1=1.27&r2=1.28&pathrev=MAIN)

[dansrfe]

I'm getting a "Addborders must add by mod2" error which I never got with the 2.5.8 MT build and have been adding odd values for addborders for a while with 2.5.8 MT.

[kemuri-_9]

I'm getting a "Addborders must add by mod2" error which I never got with the 2.5.8 MT build and have been adding odd values for addborders for a while with 2.5.8 MT.

make sure your video's colorspace isn't something that has mod2 requirements.

[dansrfe]

The resulting resolution after doing addborders is definitely like mod8 with it going to 1920 x 1080. Colorspace is YV12.

EDIT: Do we need to install AviSynth 2.6.0 Alpha 2 from soureforge on top of the existing 2.5.8 installation (or not) and then replace the 2.6 dll by SEt?

[kemuri-_9]

The resulting resolution after doing addborders is definitely like mod8 with it going to 1920 x 1080. Colorspace is YV12.

Oh, it seems that in 2.58 the AddBorder values rounded to requirements of the colorspace.
so when you specified odd values, it either rounded down or up to the nearest compliant value.
this behavior was changed for 2.6 to throw the error.


EDIT: Do we need to install AviSynth 2.6.0 Alpha 2 from soureforge on top of the existing 2.5.8 installation (or not) and then replace the 2.6 dll by SEt?

no, you can replace SEt's 2.6 dll over the 2.5.8 installed dll, but you won't have documentation matching your installed version in that case.

[dansrfe]

It's strange because i suddenly started getting this error even when I replace the dll back to 2.5.8.5. I always used to use Addborders with odd values, most of the time, for adding dvd borders to make it 720 x 480 and never had any problems. Also i want to point out that I can see the preview in AvsP without the error, it's only when I preview through MPC-HC that I get the error. I hope there is some fix because I'm not sure why I've suddenly started seeing the error in MPC. I've used mod2 for a long time in on-the-fly post=processing and no errors have popped up until today :(

[boondoggle]

Could someone please just check if my error in AvsP (holding arrow key to play through a movie for 10 sec and then hangs, even without any filters) only happends for me or if its a known bug?

[Gavino]

SourceForge.net > Find Software > avisynth2 > SCM Repositories > avisynth2 > avisynth > src > core > parser > script.cpp (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/parser/script.cpp?r1=1.27&r2=1.28&pathrev=MAIN)
Thanks, Ian - I see you already had my point covered. Sorry I was too lazy to check it out before posting.

Thinking about how these new functions work, I believe that if called from a function they will return the file currently being compiled rather than the file containing the function declaration (unlike mf's and stickboy's hack with try/catch from this thread (http://forum.doom9.org/showthread.php?t=66627)). Personally I think that is prefererable (and it would be difficult to do it any other way), but it's something users need to be aware of.

[kemuri-_9]

It's strange because i suddenly started getting this error even when I replace the dll back to 2.5.8.5. I always used to use Addborders with odd values, most of the time, for adding dvd borders to make it 720 x 480 and never had any problems. Also i want to point out that I can see the preview in AvsP without the error, it's only when I preview through MPC-HC that I get the error. I hope there is some fix because I'm not sure why I've suddenly started seeing the error in MPC. I've used mod2 for a long time in on-the-fly post=processing and no errors have popped up until today :(

As I've not seen what AvsP does nor have I ever used it, I don't know why you don't get the error there but do get it with mpc-hc.
It could be converting to RGB which would allow for non mod2 values...

Truthfully i prefer the error over 'just working' in this situation:

when i had a YV12 video and did AddBorders(0,1,0,1), the 1 pixel top was rounded down to 0 and the 1 pixel bottom was rounded up to 2.
This also has it to where AddBorders(0,1,0,0) does absolutely nothing and AddBorders(0,0,0,1) adds 2 pixels to the bottom.

This 'just working' situation is irregular and it should've thrown an error to begin rather than working in the above cases.

I would suggest that you conform to the change and stop using values in AddBorders that is not compliant with the colorspace you are using.

[IanB]

Given this thread is about SEt's build of the old CVS Avisynth_26 code parking branch, I am quite surprised at how few problems people actually have had. None of the code in that branch was ever tested past the ability to clean compile. I do remember fixing the code for AddBorders() and Letterbox() to handle the new planar formats, so it's quite likely that there are bugs in this build. If there is a problem with the current AddBorders() in AviSynth 2.6.0 Alpha 2 then they should be reported in its thread

[dansrfe]

Can someone please fix this build or make a new MT build for 2.6 that doesn't throw mod2 Addborders errors.

[kemuri-_9]

Can someone please fix this build or make a new MT build for 2.6 that doesn't throw mod2 Addborders errors.

what? we have already discussed this.
using values in addborders that do not comply with the underlying csp is now a user error, fix your script.

[dansrfe]

Why is it "wrong" to use odd values in Addborders to result in a mod2 or mod4 resolution. AviSynth 2.5.8 MT doesn't cause me any problems or "green"borders or anything of the like and the result after using Addborders with odd and even values gives the exact resolution I desire without issues. I understand resizing to mod2, using functions/plugins/scripts in mod2 or mod4 or mod8 but adding black pixel rows in an odd amount doesn't seem like it should be causing "trouble".

[leeperry]

I've run a few test w/ a big script using LSF/ColorMatrix/SmoothLevels/GrainFactory3(based on AddGrainC) on XPSP3 using 4 cores off a 3.5Ghz Q9450:
Avisynth 2.57 MT: 70fps
Avisynth 2.58 MT: 53fps
Avisynth 2.6 MT: 77fps

I get 200fps w/ SmoothLevels(preset="tv2pc",multithread=2,Smode=0,useopt=true) using Avisynth 2.57, and 275fps using Avisynth 2.6....talk about being late to the party :rolleyes:

I'm not sure whether I should use MT.dll from 2.57 or 2.58? They both seem to work and I get slightly more fps from 2.57. I hope it'll be stable, thanks for the fps boost! :)

[IanB]

Why is it "wrong" to use odd values in Addborders to result in a mod2 or mod4 resolution. AviSynth 2.5.8 MT doesn't cause me any problems or "green"borders or anything of the like and the result after using Addborders with odd and even values gives the exact resolution I desire without issues. I understand resizing to mod2, using functions/plugins/scripts in mod2 or mod4 or mod8 but adding black pixel rows in an odd amount doesn't seem like it should be causing "trouble".
Well I've wasted some of my valuable time and done some archaeology to check the code SEt actually used and it is correct.

For versions 2.5.8 and prior AddBorders() silently chopped odd values to force them even :- if (vi.IsYUV()) {
// YUY2 can only add even amounts
left = left & -2;
right = (right+1) & -2;
if (vi.IsYV12()) {
xsub=1;
ysub=1;
top=top& -2;
bot=(bot+1)& -2;
}
}Thus scripts with errors were silently allow to give wrong results.

2.6 now throws a script error when a value incompatible with the current pixel format is given :- if (vi.IsYUV()) {
if (!vi.IsY8()) {
xsub=vi.GetPlaneWidthSubsampling(PLANAR_U);
ysub=vi.GetPlaneHeightSubsampling(PLANAR_U);
}

const int xmask = (1 << xsub) - 1;
const int ymask = (1 << ysub) - 1;

// YUY2, etc, ... can only add even amounts
if (_left & xmask)
env->ThrowError("AddBorders: YUV image can only add by Mod %d (left side).", xmask+1);
if (_right & xmask)
env->ThrowError("AddBorders: YUV image can only add by Mod %d (right side).", xmask+1);

if (_top & ymask)
env->ThrowError("AddBorders: YUV image can only add by Mod %d (top).", ymask+1);
if (_bot & ymask)
env->ThrowError("AddBorders: YUV image can only add by Mod %d (bottom).", ymask+1);
}Only Y8 and YV24 can have arbitrary odd values for AddBorders()

[dansrfe]

Then why do I still get the desired output resolution after addborders is used with calculated values using addition of the borders? For example if I have a video that has the correct A/R at 720 x 358 and I want to add borders to make it 720 x 480 (disregard all A/R flags atm); why does this work? Why do I get exactly 720 x 480 while using addborders(0,61,0,61)? If it does indeed round the addborder parameters to mod2 in 2.5.8 then why don't I get something like 720 x 478?

[Gavino]

If it does indeed round the addborder parameters to mod2 in 2.5.8 then why don't I get something like 720 x 478?
Because it rounds the top border down to mod2 (giving 60) and the bottom border up to mod2 (giving 62).

[dansrfe]

ah^. That clears up the confusion for me :). Ok I guess I'll have to revise my scripts a bit then :D

[Boulder]

Does anyone have a recent MT build? Avisynth 2.6 has had quite a few fixes since September 2009.

[leeperry]

Does anyone have a recent MT build? Avisynth 2.6 has had quite a few fixes since September 2009.
http://forum-images.hardware.fr/images/perso/rastaman40.gif

[DVDBob]

Can i to this:
MPEG2Source("My movie.d2v",cpu=0)
Crop(14,2,-18,-10)
mt("""MCTemporalDenoise(settings="low")""")

Or should i do this:
SetMTMode(5,0)
MPEG2Source("My movie.d2v",cpu=0)
Crop(14,2,-18,-10)
MCTemporalDenoise(settings="low")
SetMTMode(2,0)

I have a 2 core cpu.

[Fullmetal Encoder]

Has anyone tried FFMS2 with Avisynth 2.6? I have been able to set up the x64 FFMS2 to work with JoshyD's 64-bit 2.5.8 Avisynth but after hearing such great performance out of SEt's 2.6 I decided to run some benchmarks with it to see if I could do better than I have been but I can't get a single version of FFMS2 to work with it. I've tried the vanilla ffmpegsource-2.14 and ffmpegsource-2.1.4-mt both with SetMTMode and without and all I get is a VirtualDub that just hangs or throws a KERNALBASE error or an Avisynth read error (unknown exception).

I've been using SEt's 2.6 version released 09/19/2009 with the following script (the most basic script I've attempted):

LoadPlugin("X")
FFVideoSource("Y")
QTGMC(Preset="Slow")
SelectEven()

Where X is the full path to FFMS2.dll and Y is the full path to the MKV I'm working with. What I'm doing is dragging and dropping this avs script onto the 32-bit VirtualDub, selecting "Direct stream copy" in VirtualDub and then saving the file as an AVI. The process seems to work for a few seconds as VirtualDub's progress window pops up but I inevitably get "Error reading source frame 0: Avisynth read error: Avisynth: unknown exception." I've tried using SetMemoryMax() to no avail as well as various SetMTMode values without any success. I've also double checked to make sure my paths are correct and that I'm using the 2.6 version of Avisynth from the version.avs script.

I'm using a Core i7 860 with 8GB of RAM running Windows 7 Professional 64-bit. This problem is starting to drive me nuts as I have a pretty powerful system but can't use more than a fraction of it for my encoding and despite the searching I've done in the forums and on the internet I can't figure out what could be causing this.

I would very much appreciate it if someone could shed some light on this for me.

Thanks in advance!

[Didée]

I've been using SEt's 2.6 version released 09/19/2009 with the following script (the most basic script I've attempted):

LoadPlugin("X")
FFVideoSource("Y")
QTGMC(Preset="Slow")
SelectEven()
The most basic script you have tried is - a script with QTGMC. Now, look at that.


drive me nuts as I have a pretty powerful system but can't use more than a fraction of it for my encoding
I've pretty much the same HW as you, and have no problems to use 90~99% CPU for filtering+encoding. With 2.5.8.5.MT, that is.

[DVDBob]

Nobody can help me???

[Fullmetal Encoder]

The most basic script you have tried is - a script with QTGMC. Now, look at that.

Well, by "basic" I meant without any funky MT modes set and without any options specified in FFVideoSource. But I did go back and re-run the test without QTGMC and, low and behold, FFMS2 works. So, I guess we can say that FFMS2 works with 2.6 so long as I don't put any scripting in my script ;) Since I had had similar errors with FFMS2 in 64-bit but not had any problems with QTGMC in 64-bit I just assumed that the read error was produced by FFMS2. However, my new discovery doesn't help me much as not using QTGMC is somewhat of a deal-breaker for me so I suppose my question becomes:

Has anyone out there had any success using QTGMC with 2.6 and FFMS2? And, if so, do you have any ideas on where I might be going wrong here?

I've pretty much the same HW as you, and have no problems to use 90~99% CPU for filtering+encoding. With 2.5.8.5.MT, that is.

I don't know if you are just making fun of me here or not but assuming you aren't I too can get 90-99% CPU usage with JoshyD's but only by specifying more than 2 cores be used. That makes enough sense but whenever I specify more than 2 cores I'm guaranteed to get a crash. What's really bizarre to me though is that while the performance I get using 2 cores is on the order of twice the performance I get using 1 core, using 4 cores dramatically reduces performance (e.g. .46 fps vs. 2.9-3 fps with 2 cores using QTGMC's slow preset). But this is a matter for the other thread.

[Fullmetal Encoder]

Can i to this:
MPEG2Source("My movie.d2v",cpu=0)
Crop(14,2,-18,-10)
mt("""MCTemporalDenoise(settings="low")""")

Or should i do this:
SetMTMode(5,0)
MPEG2Source("My movie.d2v",cpu=0)
Crop(14,2,-18,-10)
MCTemporalDenoise(settings="low")
SetMTMode(2,0)

I have a 2 core cpu.

DVDBob, I have not tested MT() much at all and not at all using 2.6 but from what I've read it's usually a problematic way of invoking multithreading. Some people say they get much better performance using MT() over SetMTMode() but from what I gather about the way the two work MT() involves splitting each frame into segments which then have to be pieced together again which often leaves artifacts in the image. If I were you I'd stick with SetMTMode.

[DVDBob]

DVDBob, I have not tested MT() much at all and not at all using 2.6 but from what I've read it's usually a problematic way of invoking multithreading. Some people say they get much better performance using MT() over SetMTMode() but from what I gather about the way the two work MT() involves splitting each frame into segments which then have to be pieced together again which often leaves artifacts in the image. If I were you I'd stick with SetMTMode.

Ok.

I have a 2 core CPU, so what setting should I use and where in my script, should I use SetMTMode???

[Tiberiust]

@DVDBob and Fullmetal...
As a recent n00b, MT Avisynth has driven me nuts...but I have recently done abt 30hrs of VHS and MPEG2 with 100% reliability using this:


LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\AddGrainC.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\AGC.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\ColorMatrix.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\ffms2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\FFT3DFilter.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\deblock.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\DctFilter.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\RemoveGrainSSE3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\RepairSSE3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\mt_masktools-25.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\deblock.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\gradfun2db.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\UnDot.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\SangNom.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\TTempSmooth.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\FFT3dGPU.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\MT.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\DePanEstimate.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\DePan.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\SmoothAdjust-MSVC-x86.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\ChromaShift.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\SoundOut.dll")

import("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\CutFrames.avs")

import("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\GradFun2DBmod.v1.3.avsi")
import("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\Deblock_QED_MT2.avsi")
import("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\QTGMC2.51.avsi")
import("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\LSFmod.v1.9.avsi")
import("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\MCTemporalDenoise v1.4.20.avsi")
Import("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\FFMS2.avsi")

setmtmode(5,0)
FFVideoSource("blah.mpg")
AssumeTFF().converttoyv12(interlaced=true)
SetMTMode(2)
QTGMC( Preset="slow", EdiThreads=8 )
setmtmode(5)
MT("""MCTemporalDenoise(settings="medium")""", threads=8, overlap=8)
selecteven()

I tested this for you (just removed SetMTModes and QTGMC) and it seems to run fine:

FFVideoSource("blah.mpg")
AssumeTFF().converttoyv12(interlaced=true)
MT("""MCTemporalDenoise(settings="medium")""", threads=8, overlap=8)
selecteven()

Now for the bad bit...with CPU at abt 80pct (i7 at 3.8Ghz) the first script manages only 4fps on 720x576 :p I'd be interested to know if others get the same cos I'm probably making some ignorant mistake somewhere?

I guess other source filters would be happy with it as well. However, note that I use SEt's 2.58 MT, his 2.6 is compiled from very early sources of 2.6 development - I recall a post from Avisynth devs saying they were suprised it worked wout more problems.

T

[Gavino]

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\TibPlugins\mt_masktools-25.dll")
...
SetMTMode(2)
...
setmtmode(5)
MT("""MCTemporalDenoise(settings="medium")""", threads=8, overlap=8)
With Avisynth 2.6, you should be using mt_masktools-26.dll.
Otherwise, mysterious crashes may occur.

Also, it's not necessary to use setmtmode(5) before calling MT(), as MT itself does this (or its equivalent) internally.

[Fullmetal Encoder]

Interesting. I have re-run my tests and this time I kept careful track of which versions of Avisynth I was testing and what I'm finding is that QTGMC seems to bork everything except JoshyD's 04/10/2010 x64 release of Avisynth (the newest version doesn't work). What's odd is that I can't get my system to use more than about 30% of the CPU with any performance increase. Using the "basic" script I provided earlier the best I can achieve is about 2.6-2.8 fps with 30% usage. That's with SetMTMode(5,2) at the top and SetMTMode(2) just before QTGMC. QTGMC obviously takes longer than FFMS2 does to feed it the video but what surprises me is that even specifying 8 threads throughout the fps drop to something on the order of .46. On his QTGMC thread even -Vit- states that the plugin has "also been used extensively with SeT's MT build of AviSynth 2.6 with 8 (and more) threads." :mad: Maybe my best results are all I'm going to be able to squeeze out of it but it still bugs me that I've all this RAM and processing power just sitting around doing nothing.

I didn't know about using just mt_masktools-26.dll with 2.6. I checked my plugin folder and found that I had both -25 and -26 in there. Masktools is a part of QTGMC so I think I'm going try some more testing with it after removing -25 and see if maybe that has anything to do with the performance. But that will have to wait until tomorrow.

As for MT() I've been a little wary of that due the artifacts I've heard it produces.

[Tiberiust]

With Avisynth 2.6, you should be using mt_masktools-26.dll.
Otherwise, mysterious crashes may occur.

Indeed, I had many a struggle with mysterious crashes mistakenly using the wrong mt_masktools version :) but I do stress that this script uses SEt's 2.58 MT.
The script I pasted is verbatim one of my defaults, it has worked perfecto on abt 30hrs of footage which in my MT experience is a major credit

Also, it's not necessary to use setmtmode(5) before calling MT(), as MT itself does this (or its equivalent) internally.

Yes, but I have previously called Setmtmode (2) to run QTGMC
and I then reset it to mode 5 since there are other filters lower down in the script (like Depan, not shown here) which don't like MT

Izzat wrong?

Tks

T

[Gavino]

Indeed, I had many a struggle with mysterious crashes mistakenly using the wrong mt_masktools version :) but I do stress that this script uses SEt's 2.58 MT.
Yes, I see now you did say that in your post.
But as this is a thread about 2.6, my warning may be useful to other readers.
Yes, but I have previously called Setmtmode (2) to run QTGMC
and I then reset it to mode 5 since there are other filters lower down in the script (like Depan, not shown here) which don't like MT

Izzat wrong?
No - just that in the short script you posted, it looked like you were calling setmtmode(5) simply to avoid multithreading the MT function. MT itself switches off the current SetMTMode setting before doing its work (and restores it afterwards).

[yup]

Hi all!

I use Set 2.6 build and QTGMC practically any week for 6-12 hr video. I do not use ffms2 and ffdshow only DirectshowSource().
Script simple:
SetMTMode(2,4)
DirectShowSource("aaa.avi")
AssumeTFF()
ConvertToYV12(interlaced=true)
QTGMC()
SelectEven()
I am try both mt_maskrtools-25.dll and mt_maskrtools-26.dll with same result.
This work stable.
yup.

[Groucho2004]

It seems that most problems are with the 64 bit variants.

I have been using SeT's Avisynth MT 2.6 (32 bit) and QTGMC for a while without any problems. It's stable with all source filters I tried, FFMS2, DGDecNV, DSS.

[DVDBob]

FFVideoSource("blah.mpg")
AssumeTFF().converttoyv12(interlaced=true)
MT("""MCTemporalDenoise(settings="medium")""", threads=8, overlap=8)
selecteven()

Now for the bad bit...with CPU at abt 80pct (i7 at 3.8Ghz) the first script manages only 4fps on 720x576 :p I'd be interested to know if others get the same cos I'm probably making some ignorant mistake somewhere?

I guess other source filters would be happy with it as well. However, note that I use SEt's 2.58 MT, his 2.6 is compiled from very early sources of 2.6 development - I recall a post from Avisynth devs saying they were suprised it worked wout more problems.

T

"threads=8" means 8 core cpu or not???

[Tiberiust]

"threads=8" means 8 core cpu or not???

Yes, I have a Core i7. For your Core 2, replace the '8' with a '2'

T

[Tiberiust]

@Yup and Groucho
Yes, SEt's 2.6 MT does work well a lot of the time esp with QTGMC. But I would suggest that you've been lucky, especially if you mix your mt_masktools versions. Based on hours of teeth grinding experimentation, I would seriously say, for general MT use, use SEt's 2.58.

I found IanB's comments (http://forum.doom9.org/showthread.php?p=1451382#post1451382) abt SEt's 2.6 MT which is enuf to put me off. IMHO unless you're very knowledgeable Avisynth MT is a crapshoot at the best of times and starting off with a dodgy version of avisynth.dll is not gonna help...

T

[DVDBob]

Should I also replace overlap=8 with overlap=2 ???

[yup]

DVDBob!
Should I also replace overlap=8 with overlap=2 ???
Read help for MVTools
http://www.avisynth.org.ru/mvtools/mvtools2.html
It is relating with MVTools plugin, not multithreading. Overlap could half block size for best motion compensation.
yup.

[Tiberiust]

Should I also replace overlap=8 with overlap=2 ???

No, coincidentally the same, that's about adding pixels where the frame is split for MT mode. It's 'trial and error' time for you m8 :p, so much of script testing is source dependent that there's no other way

read more here: http://avisynth.org/mediawiki/MT_support_page

T

[ganymede]

setmtmode(5,0)
FFVideoSource("blah.mpg")
AssumeTFF().converttoyv12(interlaced=true)
SetMTMode(2)
QTGMC( Preset="slow", EdiThreads=8 )
setmtmode(5)
MT("""MCTemporalDenoise(settings="medium")""", threads=8, overlap=8)
selecteven()
You should call SelectEven() before MCTemporalDenoise(). Actually, you're processing even and odd frames with MCTD, after what you're dropping odd frames -> it's a waste of processing time/power.

[Fullmetal Encoder]

It seems that most problems are with the 64 bit variants.

I have been using SeT's Avisynth MT 2.6 (32 bit) and QTGMC for a while without any problems. It's stable with all source filters I tried, FFMS2, DGDecNV, DSS.

That's very interesting. Groucho, would you be so kind as to tell me which versions of FFMS2, Avisynth MT 2.6 and QTGMC you are using successfully? Also, how are you invoking Avisynth? Are you using VirtualDub or avs2avi?

I just went to my plugins folder, removed mt-masktools-25.dll, removed all duplicate (or possible duplicate) plugins and re-ran a few of my tests both with FFMS2-MT and vanilla without any special MT modes set and STILL get "Avisynth read error Avisynth: unknown exception" every time. I even tried swapping out some of the vanilla plugins with their SSE3 counterparts but get the same result. I'm using QTGMC v2.5.1, FFMS2 v2.1.4 and SEt's 09/19/09 release of Avisynth 2.6. All I'm doing is selecting "Direct stream copy" in VirtualDub and saving as an AVI.

[ganymede]

I'm using successfully :
- SEt's build of avisynth 2.6 MT
- ffms2 2.14 vanilla (not -mt)
- QTGMC 2.51 (with SSE3 versions of RemoveGrain, Repair and VerticalCleaner)
All of these programs/filters in 32 bits version, and... under linux/wine :cool:
ffms2-mt is not running under wine, as far as I tried.
I'm using mainly VirtualDub for previewing and avs2yuv for encoding.

[Groucho2004]

That's very interesting. Groucho, would you be so kind as to tell me which versions of FFMS2, Avisynth MT 2.6 and QTGMC you are using successfully? Also, how are you invoking Avisynth? Are you using VirtualDub or avs2avi?

I just went to my plugins folder, removed mt-masktools-25.dll, removed all duplicate (or possible duplicate) plugins and re-ran a few of my tests both with FFMS2-MT and vanilla without any special MT modes set and STILL get "Avisynth read error Avisynth: unknown exception" every time. I even tried swapping out some of the vanilla plugins with their SSE3 counterparts but get the same result. I'm using QTGMC v2.5.1, FFMS2 v2.1.4 and SEt's 09/19/09 release of Avisynth 2.6. All I'm doing is selecting "Direct stream copy" in VirtualDub and saving as an AVI.

First of all, I use Avisynth MT 2.6 from this (http://forum.doom9.org/showthread.php?t=148782) link (2009.09.19).

I tried FFMS 2.14 with QTGMC 2.51 using typically this script (just an example):

SetMTMode(5,4)
Import("qtgmc.avsi")
LoadPlugin("ffms2.dll")
AssumeTFF()
SetMTMode(2)
QTGMC(Preset="Slow").SelectEven()
AssumeFPS(25000, 1000).ConvertToYUY2()


This I either feed directly to x264 or Procoder. I also use a tool I wrote myself to check the speed of a script. If interested you can download it here (http://www.iol.ie/~schubert/AVSInfo.zip).

[Fullmetal Encoder]

SetMTMode(5,4)
Import("qtgmc.avsi")
LoadPlugin("ffms2.dll")
AssumeTFF()
SetMTMode(2)
QTGMC(Preset="Slow").SelectEven()


Well, I just copy and pasted this part of your script into a new test script (of course I used the full paths for qtgmc and ffms2 on my system) and tried it in VirtualDub. Avisynth threw an invalid argument error on AssumeTFF(). So I deleted that line and tried again...got invalid argument error on QTGMC. It appears that either I or my computer are in the twilight zone. I'm running out of ideas. Going to have to try to do a little more testing with various FFMS2 versions later.

[Groucho2004]

Avisynth threw an invalid argument error on AssumeTFF()

As I said, it's just an example.

Download the tool I linked to in my last post (AVSInfo) and check the error message it returns.

Edit: And post your entire script.

[Gavino]

Avisynth threw an invalid argument error on AssumeTFF(). So I deleted that line and tried again...got invalid argument error on QTGMC.
The script is missing a call to the source filter.

[Fullmetal Encoder]

As I said, it's just an example.

Download the tool I linked to in my last post (AVSInfo) and check the error message it returns.

Edit: And post your entire script.

As to Gavino's post, yes I realized my error about 20 minutes after posting my last message and corrected that. Please disregard my message about the invalid argument errors and sorry about the hassle. That's what I get for being in a hurry. After adding the source call and re-running it I received the familiar KERNELBASE error I've gotten in prior attempts to get QTGMC working. This one seems to occur only when I invoke SetMTMode(). Here is the script I am using:


SetMTMode(5,4)
Import("QTGMC.avsi")
LoadPlugin("ffms2.dll")
FFVideoSource("X.mkv")
SetMTMode(2)
QTGMC(Preset="Slow").SelectEven()

Where X is the path to my MKV file. Luckily, unlike the Avisynth read error I otherwise get, VirtualDub gives me extended information on the KERNELBASE crash. Here is the whole of the text it gives me as maybe someone here can interpret it:


VirtualDub crash report -- build 32842 (release)
--------------------------------------

Disassembly:
76ebb6a0: 93 xchg eax, ebx
76ebb6a1: a9eb76e878 test eax, 78e876eb
76ebb6a6: b5ff mov ch, 0ffh
76ebb6a8: ffc7 inc edi
76ebb6aa: 40 inc eax
76ebb6ab: 24bc and al, 0bch
76ebb6ad: a9eb76c3cc test eax, ccc376eb
76ebb6b2: cc int 3
76ebb6b3: cc int 3
76ebb6b4: cc int 3
76ebb6b5: cc int 3
76ebb6b6: e866b5ffff call 76eb6c21
76ebb6bb: 33c9 xor ecx, ecx
76ebb6bd: 8178206aa9eb76 cmp dword ptr [eax+20h], 76eba96a
76ebb6c4: 0f94c1 setz cl
76ebb6c7: 8bc1 mov eax, ecx
76ebb6c9: c3 ret
76ebb6ca: cc int 3
76ebb6cb: cc int 3
76ebb6cc: cc int 3
76ebb6cd: cc int 3
76ebb6ce: cc int 3
76ebb6cf: 8bff mov edi, edi
76ebb6d1: 55 push ebp
76ebb6d2: 8bec mov ebp, esp
76ebb6d4: 83ec50 sub esp, 50h
76ebb6d7: 8b4508 mov eax, [ebp+08h]
76ebb6da: 8945b0 mov [ebp-50h], eax
76ebb6dd: 8b450c mov eax, [ebp+0ch]
76ebb6e0: 83e001 and eax, 01h
76ebb6e3: 8945b4 mov [ebp-4ch], eax
76ebb6e6: 33c0 xor eax, eax
76ebb6e8: 8945b8 mov [ebp-48h], eax
76ebb6eb: c745bccfb6eb76 mov dword ptr [ebp-44h], 76ebb6cf
76ebb6f2: 394514 cmp [ebp+14h], eax
76ebb6f5: 7423 jz 76ebb71a
76ebb6f7: 8b4510 mov eax, [ebp+10h]
76ebb6fa: 83f80f cmp eax, 0fh
76ebb6fd: 7603 jbe 76ebb702
76ebb6ff: 6a0f push 0fh
76ebb701: 58 pop eax
76ebb702: 8945c0 mov [ebp-40h], eax
76ebb705: c1e002 shl eax, 02h
76ebb708: 50 push eax
76ebb709: ff7514 push dword ptr [ebp+14h]
76ebb70c: 8d45c4 lea eax, [ebp-3ch]
76ebb70f: 50 push eax
76ebb710: e80da90200 call 76ee6022
76ebb715: 83c40c add esp, 0ch
76ebb718: eb03 jmp 76ebb71d
76ebb71a: 8945c0 mov [ebp-40h], eax
76ebb71d: 8d45b0 lea eax, [ebp-50h]
76ebb720: 50 push eax
76ebb721: ff156c11eb76 call dword ptr [76eb116c]
76ebb727: c9 leave <-- FAULT
76ebb728: c21000 ret 0010
76ebb72b: cc int 3
76ebb72c: cc int 3
76ebb72d: cc int 3
76ebb72e: cc int 3
76ebb72f: cc int 3
76ebb730: 8bff mov edi, edi
76ebb732: 55 push ebp
76ebb733: 8bec mov ebp, esp
76ebb735: 56 push esi
76ebb736: 8b7508 mov esi, [ebp+08h]
76ebb739: 83fef4 cmp esi, 0f4h
76ebb73c: 7218 jc 76ebb756
76ebb73e: 83fef6 cmp esi, 0f6h
76ebb741: 7713 ja 76ebb756
76ebb743: 8d4508 lea eax, [ebp+08h]
76ebb746: 50 push eax
76ebb747: 6a00 push 00h
76ebb749: 56 push esi
76ebb74a: e8dd020000 call 76ebba2c
76ebb74f: 85c0 test eax, eax
76ebb751: 7403 jz 76ebb756
76ebb753: 8b7508 mov esi, [ebp+08h]
76ebb756: 56 push esi
76ebb757: ff153c10eb76 call dword ptr [76eb103c]
76ebb75d: 5e pop esi
76ebb75e: 85c0 test eax, eax
76ebb760: 7c05 jl 76ebb767
76ebb762: 33c0 xor eax, eax
76ebb764: 40 inc eax
76ebb765: eb08 jmp 76ebb76f
76ebb767: 50 push eax
76ebb768: e8c5ae0200 call 76ee6632
76ebb76d: 33c0 xor eax, eax
76ebb76f: 5d pop ebp
76ebb770: c20400 ret 0004
76ebb773: cc int 3
76ebb774: cc int 3
76ebb775: cc int 3
76ebb776: cc int 3
76ebb777: cc int 3
76ebb778: 8bff mov edi, edi
76ebb77a: 55 push ebp
76ebb77b: 8bec mov ebp, esp
76ebb77d: 8b450c mov eax, [ebp+0ch]
76ebb780: 83f8f4 cmp eax, 0f4h
76ebb783: 742c jz 76ebb7b1
76ebb785: 83f8f5 cmp eax, 0f5h
76ebb788: 7416 jz 76ebb7a0
76ebb78a: 83f8f6 cmp eax, 0f6h
76ebb78d: 7531 jnz 76ebb7c0
76ebb78f: 64a118000000 mov eax, fs:[00000018]
76ebb795: 8b4030 mov eax, [eax+30h]
76ebb798: 8b4010 mov eax, [eax+10h]
76ebb79b: 8b4018 mov eax, [eax+18h]
76ebb79e: eb20 jmp 76ebb7c0

Built on Aegis on Fri Dec 24 13:18:44 2010 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7600) []

EAX = 153eedd0
EBX = 00000000
ECX = 00000003
EDX = 00000000
EBP = 153eee20
ESI = 032f1aa0
EDI = 002f7640
ESP = 153eedd0
EIP = 76ebb727
EFLAGS = 00000212
FPUCW = 027f
FPUTW = ffff

Crash reason: Unhandled Microsoft C++ Exception

Crash context:
An exception occurred in module 'KERNELBASE'.

Pointer dumps:

EAX 153eedd0: e06d7363 00000001 00000000 76ebb727 00000003 19930520 153eee68 032c18b8
ESI 032f1aa0: 032b6fb8 0329a6c0 00000000 00000001 00000000 00000000 0ec88bce 00000000
EDI 002f7640: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ESP 153eedd0: e06d7363 00000001 00000000 76ebb727 00000003 19930520 153eee68 032c18b8
153eedf0: 0000001c 032566d9 007c1f54 002f7640 00000000 032f1aa0 153eee14 032571e2
153eee10: 032f1f08 153eee54 03255e04 00000008 153eee58 0324c3ea e06d7363 00000001
153eee30: 00000003 153eee4c e06d7363 00000001 00000000 00000000 00000003 19930520
EBP 153eee20: 153eee58 0324c3ea e06d7363 00000001 00000003 153eee4c e06d7363 00000001
153eee40: 00000000 00000000 00000003 19930520 153eee68 032c18b8 153eee74 0324c161
153eee60: 153eee68 032c18b8 032b6fb8 0329a6c0 00000000 00000001 031529bc 002f7640
153eee80: 007c0a80 8b7ffffe 153eef30 032709bb 00000000 031549ba 4daaed50 007c0a80

Thread call stack:
76ebb727: KERNELBASE!RaiseException [76eb0000+b6cf+58]
76ebb727: KERNELBASE!RaiseException [76eb0000+b6cf+58]
032566d9: AviSynth!DllGetClassObject [03150000+e7d0+f7f09]
032571e2: AviSynth!DllGetClassObject [03150000+e7d0+f8a12]
03255e04: AviSynth!DllGetClassObject [03150000+e7d0+f7634]
0324c3ea: AviSynth!DllGetClassObject [03150000+e7d0+edc1a]
0324c161: AviSynth!DllGetClassObject [03150000+e7d0+ed991]
031529bc: AviSynth!000029bc
031549ba: AviSynth!000049ba
03154a2b: AviSynth!00004a2b
031550bb: AviSynth!000050bb
0315568c: AviSynth!0000568c
03192c53: AviSynth!DllGetClassObject [03150000+e7d0+34483]
03250753: AviSynth!DllGetClassObject [03150000+e7d0+f1f83]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
031cb5d0: AviSynth!DllGetClassObject [03150000+e7d0+6ce00]
0b7ba586: mt_masktools-26!0002a586
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
031cb5d0: AviSynth!DllGetClassObject [03150000+e7d0+6ce00]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0b7bc5c3: mt_masktools-26!0002c5c3
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
03154a6c: AviSynth!00004a6c
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
022a6d0d: RemoveGrainSSE3!00006d0d
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
031ce71d: AviSynth!DllGetClassObject [03150000+e7d0+6ff4d]
031cf022: AviSynth!DllGetClassObject [03150000+e7d0+70852]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
031cb5d0: AviSynth!DllGetClassObject [03150000+e7d0+6ce00]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
773d28d6: ntdll!NtdllDefWindowProc_A [77390000+428b3+23]
0b7bc5c3: mt_masktools-26!0002c5c3
773bde63: ntdll!RtlFreeHeap [77390000+2dde5+7e]
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0c0bd00e: mvtools2!_AvisynthPluginInit2@4 [0c080000+6760+368ae]
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
773bdf32: ntdll!RtlAllocateHeap [77390000+2de86+ac]
0c088f12: mvtools2!_AvisynthPluginInit2@4 [0c080000+6760+27b2]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0315c040: AviSynth!avs_release_value [03150000+8320+3d20]
0c0881e6: mvtools2!_AvisynthPluginInit2@4 [0c080000+6760+1a86]
0c091c33: mvtools2!_AvisynthPluginInit2@4 [0c080000+6760+b4d3]
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
0b7ba586: mt_masktools-26!0002a586
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
773bdf32: ntdll!RtlAllocateHeap [77390000+2de86+ac]
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0b831486: mt_masktools-26!000a1486
031cb5d0: AviSynth!DllGetClassObject [03150000+e7d0+6ce00]
0b820ba3: mt_masktools-26!00090ba3
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
773bde63: ntdll!RtlFreeHeap [77390000+2dde5+7e]
0b7bc5c3: mt_masktools-26!0002c5c3
0b8223fe: mt_masktools-26!000923fe
0b7ba586: mt_masktools-26!0002a586
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0b7bc5c3: mt_masktools-26!0002c5c3
0b7bc6ff: mt_masktools-26!0002c6ff
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0c091bd3: mvtools2!_AvisynthPluginInit2@4 [0c080000+6760+b473]
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
760e14d1: kernel32!HeapFree [760d0000+114bd+14]
0b8223df: mt_masktools-26!000923df
0b8223fe: mt_masktools-26!000923fe
773be1cc: ntdll!RtlInitUnicodeString [77390000+2e068+164]
773bdf32: ntdll!RtlAllocateHeap [77390000+2de86+ac]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0b7bc5c3: mt_masktools-26!0002c5c3
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0318e34f: AviSynth!DllGetClassObject [03150000+e7d0+2fb7f]
0315a5ba: AviSynth!avs_release_value [03150000+8320+229a]
0315bfb5: AviSynth!avs_release_value [03150000+8320+3c95]
0315eee7: AviSynth!DllGetClassObject [03150000+e7d0+717]
760e3677: kernel32!BaseThreadInitThunk [760d0000+13665+12]
773c9d42: ntdll!RtlInitializeExceptionChain [77390000+39cdf+63]
773c9d15: ntdll!RtlInitializeExceptionChain [77390000+39cdf+36]

-- End of report


I am using the same 09/19/09 release of Avisynth 2.6 that you linked. By God there must be a solution. I did try dropping the AVS script onto the program you created but my script crashes the program with no error messages :(

[Groucho2004]

I did try dropping the AVS script onto the program you created but my script crashes the program with no error messages :(

Dropping? It's a console app, the syntax is "AVSInfo script.avs".

[Fullmetal Encoder]

Dropping? It's a console app, the syntax is "AVSInfo script.avs".

Yes, I knew it was a CL program but whether I open the command prompt window and use "AVSInfo TestScript.avs" or left-click and drag-and-drop the script onto the .exe it gives me the same result and crashes on frame 1. But using it was valuable because at least I know now that the error isn't being caused by something in VirutalDub.

[Groucho2004]

I know now that the error isn't being caused by something in VirutalDub.

There are so many things that could be wrong.

- I recall that you had 64 bit Avisynth installed and I suppose that you just overwrote the 64 bit avisynth DLL with the 32 bit version. That could be a problem, not sure.
- One of the DLLs needed for QTGMC could be causing a problem on your system.

All you can do is to systematically troubleshoot this. Start with a very simple script and then try all used filters in QTGMC one by one.

[Fullmetal Encoder]

There are so many things that could be wrong.

- I recall that you had 64 bit Avisynth installed and I suppose that you just overwrote the 64 bit avisynth DLL with the 32 bit version. That could be a problem, not sure.
- One of the DLLs needed for QTGMC could be causing a problem on your system.

All you can do is to systematically troubleshoot this. Start with a very simple script and then try all used filters in QTGMC one by one.

Ah yes, I had not thought to test all the used filters individually. I will report back here with the results when I can.

[Fullmetal Encoder]

Ok, I'm back. I went through and indvidually tested every one of the necessary plugins for QTGMC except for masktools and mvtools as they are very difficult to test due to their complexity. Every other plugin, independently, works just fine using the following script:


SetMTMode(5,4)
Import("C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC.avsi")
LoadPlugin("PATH TO FFMS2")
FFVideoSource("PATH TO MKV")
SetMTMode(2)
PLUGIN.SelectEven()


In fact, they work very well giving nice fps numbers. Yet, when I use QTGMC as the PLUGIN I get KERNELBASE error every time. In order to retest I went ahead and re-downloaded every plugin, fresh, as linked from the main QTGMC thread here on Doom9. I also downloaded and copied over a fresh Avisynth 2.6 (the same one you linked earlier and dated 09/19/09 by SEt). Through all of this new testing I simplified the script somewhat and discovered that if I remove line 5 from the above script (SetMTMode(2)) the KERNELBASE error vanishes and instead I get the good old "Avisynth read error Avisynth: unknown exception" crash. This is true whether I use SetMTMode(2) or SetMTMode(2,4), for example. Removing SelectEven() was also tested without success. I also made sure that the correct fftw3.dll was placed in my SysWow64 folder. I went through my plugins folder, removed all of the plugins that were not needed by QTGMC, confirmed that I had MT.dll version .7 in the plugins folder, made sure that avisynth.dll was placed in the correct systems folder and that I had a full 32-bit chain running for these tests using VirtualDub 32-bit. I tried replacing FFVideoSource() and the MKV I've been using with DirectShowSource() and an AVI and consistently received the same errors. Although I could not fully test every separate function of mvtools I did try two different versions (2.5.11.1 and 2.5.10) and still receive the same errors each time. I also tried using a previous version of MT.dll (.6) and received the same results. I even went and downloaded the new QTGMC (version 3.0), released just today, and still received both the KERNELBASE and "Avisynth read" errors in my tests. I also tried running VirtualDub with administrator privileges without success. However, this is not the only windows installation I have. I have a separate Windows 7 Professional 64-bit installation. So I tried booting into that system, re-downloading all of the relevant plugins and programs as discussed above and re-ran the script above and I STILL received the same KERNELBASE and "Avisynth read" errors :eek: As a last ditch effort I reorganized everything so that the script, source file, Avisynth, and VirtualDub softwares were all on the same drive (up until then they had all been on different drives) without success. The only thing left that I can think of is that there is something very wrong with the decoding process. I currently have a rather fresh install of the K-lite codec pack on this system (where I've done most of the work and where this all started on). I plan on uninstalling it, re-installing just the codecs I need and rerunning the tests. So far it seems that I've either made some horribly noobish mistake, which is admittedly still possible, or that I've discovered some freakish bug in 2.6 or masktools or mvtools. If anybody has any other ideas about what, or how, I could test this to narrow down the issue, please let me know. Round two begins tomorrow. Wish me luck.

[Groucho2004]

I currently have a rather fresh install of the K-lite codec pack on this system

That might well be at least one of your problems.

K-lite is an evil spawn of the darkest vigors of hell, each file of this malicious abomination has (or ought to have) a checksum of 666.

[Gavino]

if I remove line 5 from the above script (SetMTMode(2)) the KERNELBASE error vanishes and instead I get the good old "Avisynth read error Avisynth: unknown exception" crash.
What if you remove SetMTMode altogether (ie run single-threaded)?
confirmed that I had MT.dll version .7 in the plugins folder
MT.dll is only needed if you use the MT() function, not for SetMTMode().
I currently have a rather fresh install of the K-lite codec pack on this system
Since ffvideosource does not use installed codecs, K-lite is not to blame (despite its poor reputation in some quarters).
If anybody has any other ideas about what, or how, I could test this to narrow down the issue, please let me know.
I would first eliminate the multi-threading aspects and try to find the source of the error you get in single-threaded mode (which is probably the real origin of the problem).

[Didée]

Haven't tried QTGMC under Avisynth 2.6 yet, but I can confirm that TGMC_b2 works fine. (After all, TGMC/QTGMC use the very same plugins.)

Observations:

a) Where TGMC + SetMTmode(2,4~6) would crash occasionally in Avisynth 2.5.8.5.MT, it seems rock stable in Avisynth 2.6 (SEt's 09-19 build).

b) in Avisynth 2.5.8.5.MT, QTGMC + SetMTmode(2,4~6) crashes more often for me than TGMC does. Can't tell why, it just is like that.


Question is - what sorts of "MT-related fixes" have been done to 2.6, that 2.5.8.5 is missing? :devil:

[JEEB]

Since Avisynth 2.6 builds are rare and far away from each other, I thought about doing some trunk builds from now on for those interested. Build environment currently consists of MSVS2010 with the Win7 SDK and the July 2010 DirectX SDK with ddraw.lib added, so these runtimes will most probably be needed to run the library.

These are strictly experimental builds, and thus the package contains both debug and release binaries.

2011-01-25
VS2010 (http://www.mediafire.com/?lbn8xqj71a117ba) | VS2008 (http://www.mediafire.com/?9olunx1ss6erlj3) | Sources (https://github.com/jeeb/avisynth2/zipball/avisynth26_trunk_20110125)

[Zep]

cool will test it over the weekend and if any show stoppers i will let you know. :)

[Gavino]

Build environment currently consists of MSVS2010
Unfortunately, that prevents use of older OS versions such as Windows 2000. Could you possibly use VS2008 or earlier?

[JEEB]

Unfortunately, that prevents use of older OS versions such as Windows 2000. Could you possibly use VS2008 or earlier?
I have VS2008 set up as well, so I'll do a build in a while (I do hate the fact that Visual Studios older than 2010 save the include/lib/etc. settings globally instead of saving them per-project).

I could also mention here that this version of Windows is now without official support as well, but since it's NT5-based and VS2008 can make binaries that work on it, I'll pass on that :) .

[Fullmetal Encoder]

What if you remove SetMTMode altogether (ie run single-threaded)?

Earlier on, this is what I had done. For example, if I use this:


Import("C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.0.avsi")
LoadPlugin("ffms2.dll")
FFVideoSource("X.mkv")

Everything works fine. I can select Direct Stream Copy in VirtualDub and re-save the file. If, however, I use:


Import("C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.0.avsi")
LoadPlugin("ffms2.dll")
FFVideoSource("X.mkv")
QTGMC(preset="fast")

I get "Avisynth read error Avisynth: unknown exception" a few dozen frames into the process. Omitting Import() doesn't change anything either. When using SetMTMode() before QTGMC() I always get the KERNELBASE error on frame 1. While VirtualDub provides me with an "advanced" report on the KERNELBASE crash it doesn't give me any information at all on the read error. This is true whether I use "fast" or "slow" as the preset for QTGMC. I would suspect some kind of corruption in a used Windows component but then that component would have to be corrupt in just the same way in two different installations to reproduce the same errors in both. In that vein, are there any DLLS that you think might commonly be present on a coder's system that wouldn't be on a system like mine? Like something in windows that might be invoked by mvtools/masktools/avisynth? I did have a crash with VirtualDub before I began working on this problem wherein it died while attempting to run a script with a message telling me that I needed some vcomp100.dll. I subsequently tracked it down and put it in the right folder and it stopped complaining after that. In case you are wondering if that might be the culprit here, it isn't, as I've tested and get the same errors on the above script without vcomp100.dll.

MT.dll is only needed if you use the MT() function, not for SetMTMode().

Yes, I recall reading this in one of the threads here in the past but I had forgotten. And now I remember again :) No harm done though as I'm just grasping at straws at this point to look for clues.

Since ffvideosource does not use installed codecs, K-lite is not to blame (despite its poor reputation in some quarters).

This is good to know as I have yet to rip k-lite out of my system and I have it set up properly atm.

...find the source of the error you get in single-threaded mode (which is probably the real origin of the problem).

Yes, I suspect they are caused by the same source. Is there some kind of process explorer that I could use that might shed some light on what's really going on when I run the script that produces the Avisynth read error?

Also, is there something about the video file itself that could be causing the error? I can't imagine what it could be but both the AVI and the MKV I've tested are the same source material. Maybe it just doesn't like my anime.

[Groucho2004]

Is there some kind of process explorer that I could use that might shed some light on what's really going on when I run the script that produces the Avisynth read error?

Sure, the one and only Sysinternals Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653)

[levi]

jeeb are you doing 64 bit builds? :)

[yup]

Haven't tried QTGMC under Avisynth 2.6 yet, but I can confirm that TGMC_b2 works fine. (After all, TGMC/QTGMC use the very same plugins.)

Observations:

a) Where TGMC + SetMTmode(2,4~6) would crash occasionally in Avisynth 2.5.8.5.MT, it seems rock stable in Avisynth 2.6 (SEt's 09-19 build).

b) in Avisynth 2.5.8.5.MT, QTGMC + SetMTmode(2,4~6) crashes more often for me than TGMC does. Can't tell why, it just is like that.


Question is - what sorts of "MT-related fixes" have been done to 2.6, that 2.5.8.5 is missing? :devil:
Didée!
Can You confirm error for nnedi3_rpow2 for YUY2 colorspace under Set 2.6 build?
yup.

[JEEB]

jeeb are you doing 64 bit builds? :)

Maybe when I learn how to make sure code is Win64 compliant and when a friend of mine gets through porting Avisynth's asm into x264ASM usable via yasm ;) .

Also, added a VS2008 build onto the original post :) .

[kemuri-_9]

Maybe when I learn how to make sure code is Win64 compliant and when a friend of mine gets through porting Avisynth's asm into x264ASM usable via yasm ;) .

IMO 64bit support should've been done this way to start with...

[ajp_anton]

Since Avisynth 2.6 builds are rare and far away from each other, I thought about doing some trunk builds from now on for those interested. Build environment currently consists of MSVS2010 with the Win7 SDK and the July 2010 DirectX SDK with ddraw.lib added, so these runtimes will most probably be needed to run the library.

These are strictly experimental builds, and thus the package contains both debug and release binaries.

2011-01-25
VS2010 (http://www.mediafire.com/?lbn8xqj71a117ba) | VS2008 (http://www.mediafire.com/?9olunx1ss6erlj3) | Sources (https://github.com/jeeb/avisynth2/zipball/avisynth26_trunk_20110125)
Could you make them SetMTmode compatible?

[Fullmetal Encoder]

Well, I can now happily report that I have completely resolved my bizarre KERNELBASE and unknown exception crashes with Avisynth 2.6. It occurred to me to go back and check to make sure that there weren't any memory access issues since this is 32-bit softwares. I found Avisynth crashing with these errors after running up to 1.6GB of RAM used. At first I didn't get it because previously I had tested my script with SetMemoryMax and had gotten the same errors. But I thought I'd test again with a very low limit at 1.2GB and when I did it worked flawlessly, zero crashes. I tested different values and got it up as far as 1500MB without crashing. I took a look at the script with which I had previously tested SetMemoryMax (I kept a record of all the scripts I had been testing) and found that the lowest I had gone in setting the memory limit was 1600MB, which turned out to be lowest level at which the crashes occur :rolleyes: If I just tried the script with 100MB less memory it would have worked.

And now I can report some preliminary test results. The script I've been posting, without invoking SetMTMode processes with 2.6 at about 2.5fps. This is comparable to what I was getting with JoshyD's. When I invoke SetMTMode(5,4) at the top and SetMTMode(2) just before QTGMC I get over 5fps :eek: This is about twice as fast as JoshyD's running the same script with SetMTMode! Although that's a little unfair as I had tested JoshyD's with QTGMC 2.51 the v3.0 wasn't speed related so I don't think there would be much difference.

Thanks to everybody who tried to help with this. It made sense to me when I first started testing with SetMemoryMax to leave some slack between the limit and 2GB but I had no idea it needed to be that large.

[yup]

Hi all!
I find that YToUV() with YUY2 do not work for Set 2.6 build. VirtualDub try show half horizontal size frame and crash. This reason why do not work nnedi3_rpow2().
yup.

[Emulgator]

Just playing around:

SEt's avisynth.dll 32 MT Build 2.6.0 2009 09 19 in sysWOW64 on a Win7U64.
CPU i7920XM, 8GB RAM, SetMemoryMax=1536

Uncompressed PAL SD YUV source
AviSource()
RemoveDirtMC()
BlindDeHalo3(...)
MedSharp2(strength=6)
GrainFactory3(....)
Feeding VirtualDub 1.9.10 to render as uncompressed YUV.

Renders 50 frames in VirtualDub 1.9.10, then raises unknown exception.
No matter if script uses SetMTMode or not. Lowering SetMemoryMax to 768 did not help.


The same script on same engine, same system
with straight avisynth.dll 2.5.8.5 non-MT in sysWOW64 :
Both MemoryMax values run properly.
VirtualDub uses ~600MB.

Different system (WinXP32 SP3, CPU T7600G, 4GB RAM), same script
with straight avisynth.dll 2.5.8.5 non-MT in system32:
Both MemoryMax values run properly.
VirtualDub uses ~600MB.

Edit: Now finally I could catch the error message on Win7U64.
On WinXP it disappeared too quickly to even be read...

This time the script was

#---------------------------------------------------------------Sourcefilter-Calls---------------------------------------------------------------------------
AviSource("K:\E.32.00.avi")
#/*#-------------------------------------------------------------AnimeIVTC---------------------------------------------------------------------------------
ComplementParity()#Parity is vital for AnimeIVTC when performing fieldblend PAL to fullframe IVTC !
#ReverseFieldDominance(shiftup=false)#(PAL Only ! YUY2 oder RGB only) ...Like CCE's shift lines by 1
#RevFieldDom: PAL DV is expected to be sampled bottom field first.
#In case of a device sampling top field first this filter can reverse field dominance
#by simply shifting each line up (or down) by one line and duplicating the bottom (respectively top) line.
ConvertToYV12(interlaced=true)#AnimeIVTC needs YV12 !
AnimeIVTC(mode=2, aa=4, precision=3, killcomb=0, cache=15, normconv=true\
, bbob=4, omode=1, dark=0.2, thin=10, sharp=150, smooth=-1, stabilize=false, aablk=8, aaov=4, aatype="EEDI2")
#(clip i, int "mode", int "aa", int "precision", int "killcomb", int "cache", bool "ifade"\
# , bool "chrfix"\
# , bool "blend"\
# , bool "normconv"\
# , int "pattern"\
# , int "pass", bool "rendering" \
# , int "bbob", int "cbob", string "edimode", int "degrain", int "omode"\
# , int "i1", int "i2", int "e1", int "e2", int "e3", int "p1", int "p2" \
# , int "overlap", int "pel", int "search", bool "nnedi2pel", string "credconv"\
# , float "dark", int "thin", int "sharp", int "smooth", bool "stabilize", int "tradius"\
# , int "aapel", int "aaov", int "aablk", string "aatype")
#*/#--------------------------------------------------------End of AnimeIVTC-------------------------------------------------------------------------------
#/*#--------------------------------------------------------Spatial Frame Pre-Alignment-------------------------------------------------------------------
# Before Roll-Decimating a film scan, you may have to align the borders first ! Often film scans are skewed !
# VCMohan's plugins needed here: Grid, Perspective, Spinner, Reform=deskew+skew. Avoid Reform, poor resizer !
#grid(sf=0, ef=framecount, lineint=10, bold=5, vbold=2, grid=true, axis=true)#Comment grid in to see where the transformations end up
ConvertToRGB#Perspective needs RGB !
Addborders(2, 2, 2, 2)#Perspective has to discard 2 border pixels for calculations and makes these black, we pad up borders before with 2 pixels black
perspective(a=-0.00001, b=0.0, x=+1400, y=0)#Perspective needs RGB !
Crop(2, 2, -2, -2)#Perspective introduced a 2 pixel black border, we padded these up, now we crop them off
#grid(sf=0, ef=framecount, lineint=10, bold=5, vbold=2, grid=true, axis=true)#Comment grid in to see where the transformations end up
#ConvertToYV12(interlaced=true)#(RGB was needed for Perspective only)
#spinner(check=false, angle=+0.7, q=4)# sometimes exceptions thrown...
# Deskew transforms a Quadrilateral part of the frame (source at least 1 pixel per side smaller than frame)
# into a Rectangle within the frame (at least 1 pixel per side smaller than frame) Result shows stairstepping ! Poor resizer (point??)
#deskew(last, blankclip, ltopx=2, ltopy=2, lbotx=12, lboty=height-2, rtopx=width-2, rtopy=2, rbotx=width-2, rboty=height-2, resize="cubic")
#/*#------------------------------------------------------End of Spatial Frame Pre-Alignment-------------------------------------------------------------
#--------------------------------------------------Intermediate Conversions, Resizing, Assumptions------------------------------------------------------
AssumeFPS(25)#If the result of any Pulldown-Removal into 24p is to be fed into an Edius PAL-Project. Otherwise Edius will reblend 24p->25p !!!
#------------------------------------------------End of Intermediate Conversions, Resizing, Assumptions------------------------------------------------

[nhope]

I haven't tried this myself but I understand that AviSynth 2.6 MT will not accept RGB24 input. Is this so and has it been permanently dropped? If I move to 2.6 MT I would miss RGB24 support as RGB32 is slower than RGB24 in my workflow (Sony Vegas > Debugmode Frameserver > AviSynth).

[kemuri-_9]

I haven't tried this myself but I understand that AviSynth 2.6 MT will not accept RGB24 input. Is this so and has it been permanently dropped? If I move to 2.6 MT I would miss RGB24 support as RGB32 is slower than RGB24 in my workflow (Sony Vegas > Debugmode Frameserver > AviSynth).

I don't know where you heard the fact that avisynth 2.6 dropped RGB24 support...
but that's a complete lie: It's still supported.

[IanB]

AviSource() had RGB24 borked some time ago. There was a 2.58 alpha with this bug. May be SEt's build has that bug, I don't track 3rd party build, so you will have to do some archaeology to confirm or refute the issue.


Working file: avi_source.cpp
----------------------------
revision 1.14
date: 2008/07/15 06:23:21; author: ianb1957; state: Exp; lines: +10 -3
Fix RGB24 processing, add guard bytes to decompression input buffer
----------------------------

[johnmeyer]

I don't know where you heard the fact that avisynth 2.6 dropped RGB24 support...
but that's a complete lie: It's still supported.Supported or not, it no longer works for me and my particular workflow. It used to work just fine.

For 7+ years I have been frameserving out of Sony Vegas Pro into AVISynth scripts. I use the frameserver available from Debugmode (http://www.debugmode.com/frameserver/).

When you start the frameserver from Vegas, you get this dialog:

http://i177.photobucket.com/albums/w208/johnmeyer/Frameserver.gif

For seven years, I have chosen either RGB24 or YUY2, depending on my workflow, plugins used in the AVISynth script, etc. I never had a problem.

For the past several years I have been using AVISynth 2.5.8.5 multi-threaded. The DLL is dated 8/16/2009 and has the name "Jeremy Duncan August 16, 2009" in the Special Build section. This has worked very well, and works with the RGB24 option shown above.

However, in order to get better stability with the QTGMC script in multithreaded usage, I updated to AVISynth 2.6 multithreaded. The DLL is dated 8/16/2009 and is MUCH larger (1,676 KB vs. 339 KB). There is no identifier in the DLL.

When I attempt to open an RGB24 output from the frameserver, using an AVISynth script that is just one line:

AVISource("e:\frameserver.avi")

I get this error message:

http://i177.photobucket.com/albums/w208/johnmeyer/AVISynthErrorMessage.gif

RGB32 and YUY2 continue to work as they always have, but RGB32 is MUCH slower (2-3X slower) than RGB24 (or YUY2) because of the conversions done out of Vegas and perhaps because of the larger data set created. It does work just fine.

Because of subtle color shift errors when serving out using YUY2 into a script that uses QTGMC that don't happen when serving out RGB24, I would prefer to use RGB24. But, if I go back to the earlier version of AVISynth, I get stability issues in multi-threaded mode (although only with QTGMC). Typical engineering tradeoff.

So, in support of what nhope says above, I too have found that AVISynth 2.6 -- at least this particular build -- does not handle something that has worked for over seven years (for me).

Perhaps there is a different 2.6 MT build somewhere that doesn't have this problem?

[kemuri-_9]

Perhaps there is a different 2.6 MT build somewhere that doesn't have this problem?

chances of that slim, since to my knowledge, no one else has really developed a 2.6 MT build at all...

[SubJunk]

Hey guys,
I just added version information to this build because of some programs (like SVP) that read the AviSynth version.
Feel free to grab it from here (http://www.spirton.com/uploads/AviSynth/AviSynth-2.6MT-WithVersionInfo.zip).

It is exactly the same as the 2009.09.19 build from the first post, but with the added version information.

[wOxxOm]

AVS 2.6.0 Alpha 3 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/) __MT__ anyone?

[markanini]

AVS 2.6.0 Alpha 3 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/) __MT__ anyone?

Plus one

[JEEB]

MT was removed from the trunk, and, unless one of you wants to start developing a more working "multithreading" Avisynth, I think you should stop calling it out as if it was something easy to do.

Also, if you think the current multithreading model in Avisynth is good, I'd like to slap both of you a few times to drop you back into reality.

[Chikuzen]

Also, if you think the current multithreading model in Avisynth is good, I'd like to slap both of you a few times to drop you back into reality.

plus one

[um3k]

I wonder if ThreadRequest (http://forum.doom9.org/showthread.php?t=154886) could be utilized in lieu of native multithreading capability? I know I saw a script somewhere that used it to emulate the SetMTMode functionality (though it is not limited to such use). Might be worth considering.

[Zep]

Also, if you think the current multithreading model in Avisynth is good, I'd like to slap both of you a few times to drop you back into reality.

You may not like how it was implemented but fact is i get a 4X speed increase with it and unless you can and are developing a better model you should zip your lip and stop being so critical of others hard work.

[kemuri-_9]

You may not like how it was implemented but fact is i get a 4X speed increase with it and unless you can and are developing a better model you should zip your lip and stop being so critical of others hard work.

A) Sounds like you're satisfied with your current version of avisynth MT, so don't upgrade.
B) the MT model that was developed is flawed, that's the reason IanB pulled it out of the code in the first place.
C) MT models are generally not that easy to develop and it will take a lot of thought and discussion to get one that is simultaneously useful and stable, which may or may not end with requiring a break in backwards compatibility.

[JEEB]

You may not like how it was implemented but fact is i get a 4X speed increase with it and unless you can and are developing a better model you should zip your lip and stop being so critical of others hard work.
You're misreading that part of my post.

I'm not being as critical towards the back-then developer, as towards the people that think that the multithreading was removed from the trunk for no reason, and the people who think that bringing back this removed-by-main-developer feature would be easy as pie or even recommendable.

Otherwise kemuri-_9 has served all your needs and added a clear commentary on your position.

[RedDwarf1]

A) Sounds like you're satisfied with your current version of avisynth MT, so don't upgrade.
B) the MT model that was developed is flawed, that's the reason IanB pulled it out of the code in the first place.
C) MT models are generally not that easy to develop and it will take a lot of thought and discussion to get one that is simultaneously useful and stable, which may or may not end with requiring a break in backwards compatibility.

For some things it can make a very big difference. XVid encoding and the QTGMC de-interlace script to name but two, benefit from the old multi threading method.

For most HD encoding it makes no real difference or is not supported which I suspect is the real reason why some people are slamming it and saying forget it. It was done already using earlier AVISynth code, so how can the current AVISynth 2.6 MT version be that much different from the latest alpha 3 release, apart from the bug fixes and speed ups etc?

[pbristow]

Priority is surely to get a feature-complete and (reasonably) bug-free 2.6 (single-threaded) first. *Then* people can add in whatever version of MT seems best at that point. Straightjacketing the development of 2.6 to fit a model of MT that probably isn't the one we'll be using in future would be short-sighted, IMHO.

If anyone wants to create their own build of 2.6.0 Alpha 3 with added old-style MT code and see what happens, they're perfectly at liberty to do so, as I understand it.

[asarian]

So, dummy question here, but will AviSynth 2.6 no longer support multi-threading? Because that's what I'm getting from the above posts.

Would be very sad if that were the case, though. I was ere hoping we'd finally get an AviSynth version that could do multi-threading in a more robust way.

And I guess this is probably not a good time to ask for a stable 64-bit version of AviSynth, is it? :) Seriously, though, the need for multhreading -- in my cases -- is often born out of sheer necessity with the MCTemporalDenoise script, that's often just too memory/resource hungry to deal with full 1080p as a single chunk. So, an actual non-buggy non-memory-leaking-like-crazy 64-bit version of AviSynth would go a long way to avoid having to go multithreaded.

[pbristow]

asarian: It's not a question of "no longer" supporting multi-threading. MT has always been something that was *added* to the single threaded versions of AVIsynth after they were complete. [EDIT: OK, that's not really true. What I mean is, MT is an additional feature on top of the core features of AVIsynth, and has never really been a comfortable fit - hence the many problems with using it. So we have non-MT development focussed on getting the other features right, and then MT development running parallel with that, somewhat behind.) It is up to the folks who produce the MT versions to decide whether they want to do an updated MT build based any new single-threaded build.

[EDIT: And in the meantime, people are deliberating *better* ways to do multithreading in future.]

Remember, this isn't a commercial project with a boss dictating what the roadmap should be. It's a community project, where what happens depends on who's got the time, the skill, and the commitment to do what. Sketching out and agreeing roadmaps is a good idea, so that the developers can all work towards common goals rather than working at cross-purposes; but what we've seen with the AviSynth 3.0 project is that too ambitious a roadmap for the resources available just leads to stagnation and frustration all round. It's smart to keep the goals smaller and more incremental, more tightly focussed: That way, the new developments actually get finished someday.

(N.B. I am not and never have been an AVIsynth developer, just a keen user, but I've been a developer for other things and had to deal with these kinds of issues.)

[Ziddy76]

Not to be a dick, but I would hope in 2011, any project would want to be efficient MT. Just about everything it multi-core now, hell even the Tegra has 4 cores now.

[Mini-Me]

Not to be a dick, but I would hope in 2011, any project would want to be efficient MT. Just about everything it multi-core now, hell even the Tegra has 4 cores now.

The most scalable multi-threaded software tends to exploit fine-grained data parallelism to multi-thread specific areas. There are LOTS of areas for this in video filtering, but from a design standpoint, they're best handled by the authors of individual filters.

Unlike LaTo's SmoothLevels, most filters are not actually coded to be multi-threaded all by themselves, and people are demanding a generic coarse-grained solution from Avisynth developers to "fix" this. Implementing a top-down solution restricts the possibilities for parallelization, because the Avisynth developers cannot actually know how individual filters are going to access data. Some filters rely on neighboring pixels in the same frame (sometimes large neighborhoods), and some filters rely on pixels from neighboring frames (sometimes with a large radius).

Splitting the video spatially requires overlap for correctness, and the more overlap there is, the less effective parallelism becomes (and some filters need the whole picture). Splitting the video temporally can be both robust and effective, as long as filters don't rely on internal state or global variables. (Some of the MT modes actually allowed various levels of stateful behavior, but there's always a price). Ideally, this kind of parallelism should only be limited by memory (cache memory and possibly memory for separate filter instances). However, that limit can still become quite limiting if you have lots of threads and you're chaining a whole bunch of filters and/or using filters that access temporal neighbors.

Although it's not as effective as finer-grained parallelism, splitting the video temporally is a good concept. That's how the modified MT version of Avisynth worked (not the MT function, which worked spatially), but more knowledgeable posters have indicated that it was still broken. If Avisynth had been written from the ground up around this concept, I'm sure it would work great. The problem is, it's hard to hack multi-threading support into existing software that's built on lax data access/modification patterns, and it's a loooooooot harder when that software interacts with arbitrary filters written by other authors.

Ultimately, programs like Avisynth are among the most difficult possible pieces of software to safely multithread. Patching up Avisynth by itself is one thing, but whatever scheme the developers decide to use, a lot of individual filters will need to be fixed to follow it. I can understand why they want to dot their i's and cross their t's before making any final decisions.

[Rumbah]

I agree that the filters themselves should be mutithreaded (Avisynth could offer mechanisms for that).

But it would be great if the common built in ones would be multithreaded, e.g. the resize filters. It's one of the most used task and it would be great if someone could implement them multithreaded.

[ianken]

I dunno what the answer is here. But I do know that when I have a script running at 6fps and chewing 10% or less CPU on a 4Ghz six core rig I get cranky. :-)

The old MT solution (hacky as it is) helped a lot. Alas, it's a bug farm and a crap shoot.

-Ian

[Didée]

I can't tell if or by how much the current MT solutions are bugged at the core level. However, it seems that the problems are mainly caused by high memory usage. When multithreading fairly easy scripts, even with HD sources, you'll be hard pressed to find any problems.

Anyone ever noticed that all "MT problems" are with scripts that involve MVTools? Anyone has an example for problematic/unstable MT with a non-MVTools & non-ScriptClip script? :)

[asarian]

The old MT solution (hacky as it is) helped a lot. Alas, it's a bug farm and a crap shoot.

-Ian

I agree. I have the greatest respect for people involved in developing the new AviSynth, but I need MCTemporalDenoise to work properly, and for that I often really need the job split up over several threads, otherwise something runs out of memory. I know, 'something' is rather vague; but I imagine the 'solution' of multi-threading to lie along the lines of memory requirements being squared, where, say, schematically, 3 threads of 4^2 yields only 48, whereas 1 single thread of 12^2 gives a whopping 144! So I will stay with AviSynth 2.5.8 for the time being.

Also, yeah, the underusage of CPU on a single thread, even when it doesn't crash for one particular HD source, still feels like a waste.

[pbristow]

Anyone ever noticed that all "MT problems" are with scripts that involve MVTools? Anyone has an example for problematic/unstable MT with a non-MVTools & non-ScriptClip script? :)

Heh. :) Certainly MVTools is a challenge to try to multitask "from the outside", and is a prime candidate for having it's own built-in multithreading. For example, I would specify an mt version of MAnalyse so that each thread generates one quarter (if there are 4 threads) of the motion vectors for the output clip, but has access to the whole of the two input frames for matching, so that "out-of-region" matches can still be done accurately without the need for overlapped/duplicated processing (as happens currently when using MT() with a big enough overlap to cover out-of-region motion).

[ianken]

Anyone ever noticed that all "MT problems" are with scripts that involve MVTools? Anyone has an example for problematic/unstable MT with a non-MVTools & non-ScriptClip script? :)

I've observed the same. Unfortunately those tools are the heart of the most capable video-de-hosing scripts.

I've got a script now that 1) plays fine in MPC-HC with setmtmode(2) and rips along at 26fps but load it in vdub and *boom* crash in mvtools. Remove setmtmode and it's weaksauce at maybe 5fps. And this is purely SD content. It doesn't even use an entire single core when running single threaded.

So, I acknowledge that multithreaded coding is a huge challenge. No doubt. But I would hope that somewhere on the AVS roadmap is some sort of plan to allow users to take advantage of their modern rigs. Even if that means that with Version Foo.Bar we make a hard break with the existing architecture and in order to get awesome multi-core perf we need all new MT-safe plugins following a new model.

Sometimes you need to give backwards compatibility the finger.

[CruNcher]

I can't tell if or by how much the current MT solutions are bugged at the core level. However, it seems that the problems are mainly caused by high memory usage. When multithreading fairly easy scripts, even with HD sources, you'll be hard pressed to find any problems.

Anyone ever noticed that all "MT problems" are with scripts that involve MVTools? Anyone has an example for problematic/unstable MT with a non-MVTools & non-ScriptClip script? :)

For me its basicly a hit and miss thing my own scripts (simple ones, coded for speed trying to avoid complex stuff) work rather great in every Avisynth enviroment but for example scripts like MCTD either crash imidiatly trying to optimize them or crash after a while depending on the used Avisynth version lastly i got this error out from 2.6 Alpha with MCTD (trying to threadrequest)

avs [error]: Softwire: caught an access violation at 0x059b4843(code+395),
attempting to read from 0x00000000 occurred while reading frame 2058

with SVPs (OpenCL modified Motion Interpolation 2.5.8 .dll it crashes immediately @ execution ;) )

so yeah it's rather a hit and miss thing currently but once it works it's worth it :)

though the problem is also mvtools now exist in @ least 3 custom versions and then you have 2 different masktool avisynth versions + a mod version ;) and per script you are mostly forced to change your entire workflow that this can't be good is obvious and some guys should really think about building better synergies together.

[SEt]

Another threading bugfix + updated to CVS version of Avisynth.

I suggest changing SetCacheHints return value to something like intptr_t for obvious reasons.

[Groucho2004]

Another threading bugfix + updated to CVS version of Avisynth.

Could you post the source for this MT version? I see you included some source files but what about for example avisynth.h?

[SEt]

See the existing.diff for difference in files already in CVS.

[Groucho2004]

See the existing.diff for difference in files already in CVS.

Yeah, I saw that. Sorry to be a nag but I've never used CVS, can you not just upload the changed files somewhere?

[Boulder]

Thanks a lot for the new build! :)

[SEt]

No, I'm not going to post full sources with builds. If you have 'unchanged' files - you can always apply the diff manually. Also, mentioned 'threading bugfix' is only in cacheMT.cpp.

[Boulder]

I suggest changing SetCacheHints return value to something like intptr_t for obvious reasons.

Does this mean that (most) plugins need to be recompiled?

I tried the new build but I get only 25% CPU utilization on my quad-core (upon playback in VDubMod). The previous build maxes out the CPU with the same script.

[SEt]

Oops, I forgot to auto-add distributor to regular scripts. Redownload who got earlier version.

No recompilation unless they need to identify as caches, and it just underwent even greater change from void to int.

[Boulder]

Thanks, the new build works just fine.

[Didée]

No recompilation unless they need to identify as caches, and it just underwent even greater change from void to int.
Sorry if I'm a bit thick, but this does mean exactly ... what?
What's the scenario where a filter "needs to identify as cache"?

[SEt]

For example ffdshow interface for avisynth is good candidate for such cache identification when "Buffer back/ahead" is turned on - no need to insert another cache after it and waste memory.

[yup]

SEt:thanks:
Your build based on Avisynth 2.6 Alpha 3?
yup.

[Boulder]

The build is from the latest CVS sources so the code is as fresh as possible.

[levi]

Another threading bugfix + updated to CVS version of Avisynth.

Thanks Set! This rocks! Any chance we could see a 64 bit compile?

[SEt]

Maybe. I'm not very interested in 64-bit build now as I have only 6GB of ram and if you really want you can run some time-critical 64-bit code in 32-bit process too.

[SEt]

Updated to fix two ImageSource() errors. (Discussed here (http://forum.doom9.org/showthread.php?p=1513799) and here (http://forum.doom9.org/showthread.php?t=161953))

[Büke]

How about a plugin that loads any avs script into multiple processes, processes about 300 frames in each process, with 30 frames overlapping, sequentially combining the results in the master avs for final processing and encoding.

Additionally, the plugin can restart the processes to clear memory leaks.

[Mini-Me]

How about a plugin that loads any avs script into multiple processes, processes about 300 frames in each process, with 30 frames overlapping, sequentially combining the results in the master avs for final processing and encoding.

Additionally, the plugin can restart the processes to clear memory leaks.

AFAIK, coding this as an Avisynth plugin would be exceedingly difficult or even impossible, given how Avisynth works. However, it's manageable for an outside piece of software...and while I haven't tested it myself, Chikuzen has written a Python script for AvsPMod that works very similarly to what you're describing. (http://forum.doom9.org/showpost.php?p=1507911&postcount=18)

[Büke]

AFAIK, coding this as an Avisynth plugin would be exceedingly difficult or even impossible, given how Avisynth works. However, it's manageable for an outside piece of software...and while I haven't tested it myself, Chikuzen has written a Python script for AvsPMod that works very similarly to what you're describing. (http://forum.doom9.org/showpost.php?p=1507911&postcount=18)

Why would it be so difficult? Interprocess hosting and communication is often done nowadays in the audio plugin world (VST, etc.) for crossing 32-64 bit barriers, for extended memory and stability, and it is done with quiet the low latency, too.

The master plugin needs an exe host counterpart listening for commands from the scheduling master, loads and hosts the given avs, caches the requested frames and sends them back in raw format, it can even use portions of TCPServer() code.

Now I think about it, the overlapping frames are not even necessary, since Avisynth can deliver random access frames as requested by the script and plugins on demand. Runtime scripts often do not (and should not) use progressive global state variable manipulation, as most are made to be randomly seekable. This means, the processes can process less frames in parallel, such as 10-100, and maintain low memory overhead.

Macro parallelization via master controlled sub-processes is a real generic solution to this problem of utilizing all cores, it can even be built into Avisynth natively. The sub processes can even introduce additional compatibility for cross 32/64 bit hosting, and stability by restarting crashing job segments with alternate settings/scripts.

Having this done natively or via a a plugin such as ImportParallel(string AVSFile, int "ProcessCount", int "FrameCount", ...) all in memory will be a lot faster and transparent than using splitting scripts in other languages and using slow disk caches.

[SEt]

This is unrelated to this thread. I request moderators to split the posts.

Regarding the suggestion, I think another hack is not what avisynth needs today. It needs clear and mandatory rules for plugins how to deal with multithreading.

[Büke]

This is unrelated to this thread. I request moderators to split the posts.

Regarding the suggestion, I think another hack is not what avisynth needs today. It needs clear and mandatory rules for plugins how to deal with multithreading.

Why is this a hack? It is a real solution, that has been proven in other domains.

A host's mission is to make things easier for plugin authors, who would rather focus and specialize on the complexities of the algorithms, rather than their parallelization or optimization, or user interface, etc, etc.

Are you suggesting that new rules be put out and all plugins be rewritten, and new ones with additional complexities?

If the plugin authors were interested in multi-threading more than the core algorithm, they would have done this in majority of the plugins, including the native filters already..

More practical, and less dogmatic, is what I say.

[SubJunk]

Thanks a lot for the update, SEt!

[jpsdr]

Maybe. I'm not very interested in 64-bit build now as I have only 6GB of ram and if you really want you can run some time-critical 64-bit code in 32-bit process too.

Some 64bits pluggins can have sometime speed increase of 30%.
I've noticed, on QTMG for example, an increase speed of around 15% under 64bits.

My personnal thought, at the actual stage is :
The way MT is implemented on avisynth seems not to be very stable, so, the best way actualy to have a stable multithreading would be to not use MT version of avisynth, split your work and start several task. For exemple, launching 6 Vdub task on 6 files.
Using not MT version of avisynth keep garanty stability, and running several tasks make all your core work.
I think, it could be more interesting to focus on single threading 64bits port, because good 64bits port can provide good improvement in speed.
I've noticed it with the unfornutaly dead project of the 64 bits version begun by JoshyD.

[Boulder]

Does anyone else suffer from I/O operations sometimes getting very slow when encoding something using SetMTMode? I noticed the behaviour already in the old build and just got it with the new build. Creating a d2v file was getting along very slowly until I paused x264 which was using 95-99% of the CPU. The x264 process was running at idle priority so it should not cause such things. The MT'd Avisynth v2.5.8 doesn't have this issue, or at least I never noticed it.

[leeperry]

Thanks a lot for the update, SEt!
X2, :thanks:

but how can you MT w/ the new build? I'm currently using MT 0.70 w/ the 2009.09.19 2.6 build. MT 0.70 doesn't work w/ the new build, and neither does this version of MT: http://forum.doom9.org/showpost.php?p=1335913&postcount=1093

I use avisynth in realtime in ffdshow, I do need MT.

[levi]

X2, :thanks:

but how can you MT w/ the new build? I'm currently using MT 0.70 w/ the 2009.09.19 2.6 build. MT 0.70 doesn't work w/ the new build, and neither does this version of MT: http://forum.doom9.org/showpost.php?p=1335913&postcount=1093

I use avisynth in realtime in ffdshow, I do need MT.

Did you try this one:

http://code.google.com/p/avisynth64/downloads/detail?name=avisynth64_8-29-10.rar&can=2&q=

[leeperry]

Nope, coz I run a x86 OS.

[upyzl]

Sorry for my node question...

How to use it?

I installed Avisynth 2.6.0 Alpha3 [2011-05-25], but I can't find "avisynth.dll" (avs input encoding succeeded)
so how should I use the avisynth.dll from 2011.07.19, please?

[Mini-Me]

Sorry for my node question...

How to use it?

I installed Avisynth 2.6.0 Alpha3 [2011-05-25], but I can't find "avisynth.dll" (avs input encoding succeeded)
so how should I use the avisynth.dll from 2011.07.19, please?

Assuming you have a typical Windows setup, you should find Avisynth.dll in C:\Windows\system32\. Just replace the old file with the new one, and you should be good to go.

[Chikuzen]

Assuming you have a typical Windows setup, you should find Avisynth.dll in C:\Windows\system32\. Just replace the old file with the new one, and you should be good to go.

He is a 64bit Windows7 user.
so, the place of avisynth.dll is C:\Windows\SysWOW64\.

[upyzl]

Thank you :)

[naoan]

so, which MT should I use this latest build with? none seems to be working...

[SEt]

I'm not going to maintain MT plugin. Use MTMode instead.

[RedDwarf1]

Try re-encoding the same "stuff" you did on friday if you want to compare frame rates because you can't really compare different sources and expect the exact same frame rate.

Are the scripts identical? Try using AVSMeter if the scripts are different to compare the speed.

Shutting down windows could of made windows change a system file, a windows update possibly which is slowing things down. Just a guess.

If you have other software running, including browsers, in the background they can affect encoding speed.

[jeremy33]

I'm not going to maintain MT plugin. Use MTMode instead.
SetMTMode produce audio/video desync (env. 240ms) with ffdshow (and LimitedSharpenFaster). Is there a fix for that ?

With MT.dll I don't have any audio/video desync but I have to stay with avisynth 2.58. :(

[Boulder]

SEt,

do you know whether SetMTMode(2) is safe with SRestore, which is a function that uses global variables quite extensively.

[SEt]

Boulder, as I remember it's dependent on sequential frame requests, so it won't work in current MTMode regardless or global variables.

jeremy33, MTMode works perfectly fine with ffdshow here even with complex scripts like QTGMC, just make sure you have enough "Buffer ahead" frames.

[leeperry]

it does IME, but MTMode is async AFAIK, so it's a major bummer for realtime use.

[jeremy33]

Set, leeperry, it works without desync with 10/10 buffer back/ahead :)

Set, how many buffer back/ahead you recommends with this kind of script
SetMemoryMax(512)
SetMTMode(3,4)
ffdshow_source()
SetMTMode(2)
coef=1.5
newWidth=round((float(last.width)*coef)/2)*2
newHeight=round((float(last.height)*coef)/2)*2
spline64resize(newWidth,newHeight)
LimitedSharpenFaster(ss_x=1.0,ss_y=1.0,strength=45)

Thank you

[leeperry]

I get more fps w/ MT() and seeking is sluggish in SetMTMode() due to the fact that it's async.

[jeremy33]

I do not have these problems. Seeking is fast, the CPU load is the same and there is no desync.

It works like a charm for me :)

[fabje]

Ok I really just don't get it anymore.

This is my system:
Intel i7 970
Gigabyte EX58-UD3R
Kingston 3x 2GB DDR3
OCZ Vertex 2 60GB OS
2x WD 1TB Green in RAID0

And a friend of mine has the same system.
We are doing the same Windows 7 installation including the drivers and our BIOS settings are the same.
Also our Staxrip/xvid/Avisynth & plugins are the same.

But still my friend is getting 400fps in pass 1 and 250 in pass2, but I only get about 250fps in pass 1 and 200 in pass2.

And we are using the same script:
SetMTMode(5,3)
MPEG2Source("E:\Recordings\test.d2v")
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
SetMTMode(2)
LeakKernelDeint(order=1,threshold=8)
Crop(2,2,-2,-2)
BicubicResize(656,368,0,0.5)
Trim(14497,73911)

Anyone here that has a clue what is going on here?

[Boulder]

Can you check the CPU usage and number of utilized threads of both encodes?

[Zep]

well first off start by just doing this and nothing else (no MT)

MPEG2Source("E:\Recordings\test.d2v")

Get a baseline.


same hard drives and same fragmentation and source files same location on drives. I doubt it. Green drives are slow and there is NO RPM guarantee. you may get one that is 5400 RPM or you may get one that is higher. It is total luck. Always get black drives they are much faster and all 7200 RPM. Make a ram disk and test a small clip from that so the drives are not in the equation.

Same ram settings? Make sure cause ram speed plays a HUGE part in encode speed when doing FPS that high.

Same temperature? If your case is hotter you may be throttled back. Force the CPU speeds in bios do not let them float.

i could go on and on but start there lol

[fabje]

Can you check the CPU usage and number of utilized threads of both encodes?
I will do this as soon as the person who has the same system is back from his vacation.

well first off start by just doing this and nothing else (no MT)

MPEG2Source("E:\Recordings\test.d2v")

Get a baseline.


same hard drives and same fragmentation and source files same location on drives. I doubt it. Green drives are slow and there is NO RPM guarantee. you may get one that is 5400 RPM or you may get one that is higher. It is total luck. Always get black drives they are much faster and all 7200 RPM. Make a ram disk and test a small clip from that so the drives are not in the equation.

Same ram settings? Make sure cause ram speed plays a HUGE part in encode speed when doing FPS that high.

Same temperature? If your case is hotter you may be throttled back. Force the CPU speeds in bios do not let them float.

i could go on and on but start there lol
Well the two WD hardrives are in a RAID0 setup and when I do a benchmark I get these results:
http://www.fabje.eu/wd.jpg

I also have a SSD drive and with a benchmark I get the following results:
http://www.fabje.eu/ssd.jpg

When I run an encoding on both drives I get about the same speeds, so it isn't the storage drive.

Yes the ram settings are the same.

My temperature is fine during the encoding the temperature is between 40 en 50 celcuis degress depending on the core.

Also a wierd thing is that when I do a reencode with the x264 codec of a 1920 x 1080 recording to a 1280 x 720 file I get the same speeds as my friend.

[jeremy33]

jeremy33, MTMode works perfectly fine with ffdshow here even with complex scripts like QTGMC, just make sure you have enough "Buffer ahead" frames.
Actually Avisynth 2.60 and MTMode doesn't work with some kind of files, Avisynth crash.

Sample
http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_truehd_channel_check_lossless.part1.rar
http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_truehd_channel_check_lossless.part2.rar

[Zep]

I will do this as soon as the person who has the same system is back from his vacation.


indeed :)


You have SSD... does he? (SSD drivers are IMHO beta still and may be causing a conflict on your box. disable driver and see)

are the CPU/RAM speeds forced in the BIOS or not?



Also a weird thing is that when I do a re-encode with the x264 codec of a 1920 x 1080 recording to a 1280 x 720 file I get the same speeds as my friend.

well what does that tell you? It tells me you have an I/O bottleneck that he does not since x264 is so CPU heavy any I/O throughput problem is masked. This why i want the baseline with just

MPEG2Source("E:\Recordings\test.d2v")
(No encoding just that to test throughput)

because any decent box can read 40 frames a second in but when you get up to 400 FPS well.... that is a lot of data.


You may have a driver installed he does not that is slowing you down. A good example is most all anti virus. The default is for them to scan a file on OPEN READ WRITE and CLOSE. this will slow you way down and you should only need to scan once on OPEN and once on CLOSE. if you let it scan during read/write your I/O will be cut in half or more.

no need to wait for your friend if you make a ram disk and test from that. (note if you can't get at least 1 gig second read from ramdisk your anti virus or some other driver is slowing it down)


anyway just more testing needed and we will know enough... good luck

[fabje]

indeed :)


You have SSD... does he? (SSD drivers are IMHO beta still and may be causing a conflict on your box. disable driver and see)

are the CPU/RAM speeds forced in the BIOS or not?




well what does that tell you? It tells me you have an I/O bottleneck that he does not since x264 is so CPU heavy any I/O throughput problem is masked. This why i want the baseline with just

MPEG2Source("E:\Recordings\test.d2v")
(No encoding just that to test throughput)

because any decent box can read 40 frames a second in but when you get up to 400 FPS well.... that is a lot of data.


You may have a driver installed he does not that is slowing you down. A good example is most all anti virus. The default is for them to scan a file on OPEN READ WRITE and CLOSE. this will slow you way down and you should only need to scan once on OPEN and once on CLOSE. if you let it scan during read/write your I/O will be cut in half or more.

no need to wait for your friend if you make a ram disk and test from that. (note if you can't get at least 1 gig second read from ramdisk your anti virus or some other driver is slowing it down)


anyway just more testing needed and we will know enough... good luck
Yes he has a SSD but he doesn't use that for encoding.

And a little correction my friend is using 2 WD Blacks in RAID0.

My CPU/RAM speeds are indeed forced in the BIOS. So all that energy saving crap is disabled.

When I'm running the baseline I also get around 250 fps.
My anti virus software isn't the problem because I had this problem already when I just had a clean install of Windows 7 with only the drivers installed for my motherboard and graphic card. And I used the same drivers as my friend did.

[Zep]

Yes he has a SSD but he doesn't use that for encoding.

And a little correction my friend is using 2 WD Blacks in RAID0.




well that little correction is huge. I'm not saying it is the only problem but from what you said so far it is the main difference i see. Black drives get 40% more sustained throughput on reads than greens.

he gets about 400 you get about 250 well.... there you go lol


I say again. test from a ram disk to make sure. :)

[fabje]

well that little correction is huge. I'm not saying it is the only problem but from what you said so far it is the main difference i see. Black drives get 40% more sustained throughput on reads than greens.

he gets about 400 you get about 250 well.... there you go lol


I say again. test from a ram disk to make sure. :)
And how can I test from a RAM disk?

[Zep]

And how can I test from a RAM disk?

I use this and it works great (yes it is free if only 4 gig ram disk or smaller)

http://memory.dataram.com/products-and-services/software/ramdisk

then move a .ts or .mpg onto the ram disk and run your script so that it points to the source file on that ram disk. if it's an HD throughput wall you will know real quick. (assuming you are no where near 100% CPU etc... I do not recall if you mentioned that or not)

[fabje]

I use this and it works great (yes it is free if only 4 gig ram disk or smaller)

http://memory.dataram.com/products-and-services/software/ramdisk

then move a .ts or .mpg onto the ram disk and run your script so that it points to the source file on that ram disk. if it's an HD throughput wall you will know real quick. (assuming you are no where near 100% CPU etc... I do not recall if you mentioned that or not)
Well I did the test and I got the same results.
So seems like my HDD isn't the problem.

My CPU has an usage of about 50%.
I also did a check of how many threads my pc and the pc of my friend have and we are both around 880 threads.

And I did a quick HDD benchmark and this are the results:
Transfer Rate:
Minimum: 114.7MB/sec
Maximum: 156.3MB/sec
Average: 149.8MB/sec

Access Rate: 10.9ms
Burst Rate: 1295.9 MB/sec

And yes his average is higher but if I check my SSD, the SSD is faster but still this didn't changed a bit.

[Zep]

My CPU has an usage of about 50%.




so when your friend runs just MPEG2Source("E:\Recordings\test.d2v")

no encoding just a pass through FPS test he gets 400 and you get 250? You both are using same versions of software? Same bios version? same drivers versions? etc.... get process explorer and look at the avisynth threads. Compare your boxes and you should be able to see where the bottleneck is. you can even click on a single thread and see the I/O rates and much more. yeah it is time to go lower level lol


good luck

[fabje]

so when your friend runs just MPEG2Source("E:\Recordings\test.d2v")

no encoding just a pass through FPS test he gets 400 and you get 250? You both are using same versions of software? Same bios version? same drivers versions? etc.... get process explorer and look at the avisynth threads. Compare your boxes and you should be able to see where the bottleneck is. you can even click on a single thread and see the I/O rates and much more. yeah it is time to go lower level lol


good luck
No my friend gets 400fps when he is using this script:
SetMTMode(5,3)
MPEG2Source("E:\Recordings\recording.d2v")
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
SetMTMode(2)
LeakKernelDeint(order=1,threshold=8)
Crop(2,2,-2,-2)
BicubicResize(656,368,0,0.5)
Trim(9992,46915)

And yes our software version etc is the same.
The only thing that is really different is that my cpu is overclocked and his pc isn't. So I thought maybe it was an setting in my bios, but even with everything in there on default. My speeds are getting slower then what I have right now.

[IanB]

... The only thing that is really different is that my cpu is overclocked and his pc isn't. ....
Overclocking is a very black art. Try running the tests with the exact same settings as your friend.

One possible pitfall is memory access pattern, it is possible to only get down to half the effective memory speed when comparing two CPU speeds that are almost the same This happens when the slightly faster speed requires stepping down to a much crappier memory access pattern.

Also some memory controllers drop to a lower speed as you add more than a certain number of memory modules (bus loading problems). We had 2 supposedly identical servers shipped, 1 full of 1GB memory sticks the other with nice 2GB memory sticks .....

[fabje]

Overclocking is a very black art. Try running the tests with the exact same settings as your friend.

One possible pitfall is memory access pattern, it is possible to only get down to half the effective memory speed when comparing two CPU speeds that are almost the same This happens when the slightly faster speed requires stepping down to a much crappier memory access pattern.

Also some memory controllers drop to a lower speed as you add more than a certain number of memory modules (bus loading problems). We had 2 supposedly identical servers shipped, 1 full of 1GB memory sticks the other with nice 2GB memory sticks .....
I did try it with the exact same setting as my friend.
The only thing I could try is to test it with the same memory settings.

I also did a process test and this are the results when i'm encoding something on my pc.
http://www.fabje.eu/process.jpg
http://www.fabje.eu/process2.jpg

And this is a screenshot of the process explorer on the pc of my friend.
http://www.fabje.eu/process3.jpg

[matfra]

I download th last version of Avs 2.6MT. Where do I put the file diff.7z ??? I paste Avisynth.dll infor SysWow64. But I have no clue what to do with the other file. Help me please !

[-Vit-]

The diff file just contains the source code changes from the official Avisynth 2.6. Only developers need this file, you can ignore it.

[SubJunk]

Been getting occasional crashes with the new version

[mbcd]

Yes, me too

2.5.8 runs like a charm
2.5.8 MT runs at 100% Processorusage (at all cores) but crashes with nearly (95%) every job.
2.6.0 MT the same as 2.5.8

Stability is a big problem ...

[SubJunk]

Sorry, I should have been more specific with my previous post.
I meant the new version of 2.6 compared to the older 2.6; 2011.07.19 has the occasional crashes while 2009.09.19 works great for me.

[SEt]

Update, two more MT bugfixes.

I run into crash with colorspace conversion and so disabled USE_DYNAMIC_COMPILER. No crashes but slower. If speed of it is concern for you - post here, if there is enough demand I can investigate the issue. Solved, see below.

[SubJunk]

Thanks for the update, will test

[IanB]

@SEt,

In convert_planer.cpp, unpckbuf and packbuf are class local this is not thread safe.

Uncomment the _aligned_malloc and _aligned_free in the two GetFrame calls. Probably should test for malloc failures as well.

[jeremy33]

Thanks for the update Set.

All optimizations are good to take. That said I understand that it takes a long time and I prefer to have a stable soft rather than a faster soft unstable :)

:thanks:

[SEt]

Another update, redownload if you just got the build earlier today.

IanB, it should not be a problem in MTMode 2, so I left it as is for now. Found the actual crash reason: I was playing with default calling convention and missed unspecified one on dynamically generated code call. I think conventions should be explicitly written where they are important.

[asarian]

Some 64bits pluggins can have sometime speed increase of 30%.
I've noticed, on QTMG for example, an increase speed of around 15% under 64bits.

My personnal thought, at the actual stage is :
The way MT is implemented on avisynth seems not to be very stable, so, the best way actualy to have a stable multithreading would be to not use MT version of avisynth, split your work and start several task. For exemple, launching 6 Vdub task on 6 files.
Using not MT version of avisynth keep garanty stability, and running several tasks make all your core work.
I think, it could be more interesting to focus on single threading 64bits port, because good 64bits port can provide good improvement in speed.
I've noticed it with the unfornutaly dead project of the 64 bits version begun by JoshyD.

Perhaps in abundance, but I'd like to reiterate that the advantage of the often hailed speed-improvements of a 64-bit build pales in comparison to the gained memory. Especially for HD material, memory is a constant limiting factor. For instance, when using MCTemporalDenoise, I can't even run 32-bit Avisynth, unless I use a process separation trick to pipe output to x264, using avs2yuv. And even then there are times I have to split up a movie (vertically), in two parts, in order to bypass memory issues. So a good 64-bit version of AviSynth 2.6 would be very welcome.

[IanB]

IanB, ... Found the actual crash reason: I was playing with default calling convention and missed unspecified one on dynamically generated code call. I think conventions should be explicitly written where they are important.Please explain more, I don't understand where you could break this. :confused:

[SEt]

In DynamicAssembledCode::Call
return ((int (*)(const void* *))entry)(&arg1);
should be
return ((int (__cdecl*)(const void* *))entry)(&arg1);

There are plenty of other places where convention should be specified - try changing default convention to __fastcall and compile. Good thing compiler throws errors there so it's easy to spot the places.

[IanB]

Ah! You were trying to trick me. ;) Nothing to do with any convert\convert_*.cpp's it was in file core\softwire_helpers.cpp, fair enough.

[JEEB]

Couldn't get the current trunk to build, fix (https://github.com/jeeb/avisynth/commit/647a37821ce3b9aa09f64c829d47119fa3596a95). Didn't know MSVC6 compiled stuff like this :) .

[DarkT]

What has less head-ache involved, using 2.5.8 mt or 2.6? Like, I want to use up my i7-950 as best as I can, with the current x64 filters, which would be a better choice? 2.6? 2.5.8?

[TheFluff]

What has less head-ache involved, using 2.5.8 mt or 2.6? Like, I want to use up my i7-950 as best as I can, with the current x64 filters, which would be a better choice? 2.6? 2.5.8?

32-bit single-threaded 2.5.8 is by far the best choice if the purpose is to avoid headaches.

[DarkT]

32-bit single-threaded 2.5.8 is by far the best choice if the purpose is to avoid headaches.

Seems like what I wrote wasn't clear enought(perhaps not only for you) - I will restate: Least headache, while using as much of the CPU power as possible.

I do want to use multi threading. But I wonder whether 2.5.8 MT is better than 2.6. Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses? I do not know. I was hoping somebody would help me with making that decision, instead of gruelly trying it out myself.

[Groucho2004]

32-bit single-threaded 2.5.8 is by far the best choice if the purpose is to avoid headaches.

I have not had any headaches with the current 2.6 Alpha 3. :D

[Groucho2004]

I will restate: Least headache, while using as much of the CPU power as possible.
I do want to use multi threading. But I wonder whether 2.5.8 MT is better than 2.6.

That's like choosing between a migraine and a serious hangover.

Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses?
Yes.

[TheFluff]

Seems like what I wrote wasn't clear enought(perhaps not only for you) - I will restate: Least headache, while using as much of the CPU power as possible.

I do want to use multi threading. But I wonder whether 2.5.8 MT is better than 2.6. Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses? I do not know. I was hoping somebody would help me with making that decision, instead of gruelly trying it out myself.

Like Groucho2004 says, the best choice is still to use single-threaded 32-bit 2.5.8. If you want more threads, invoke more script environments.

All options other than the vanilla 2.5.8 (including all the 64-bit variants, all the MT variants and all the Avisynth 2.6 variants) are either:
a) way too unreliable,
b) way too limited, or
c) all of the above
to be useful in a production environment.

[DarkT]

64bit is a no go as well?! Blah. It's not a "production environment" either... mmm, I mean, you make it sound "serious" or something *chuckles*

I just want to encode fast... Shit... That's all... Maybe I should run 2-4 64 bits avisynth?

[TheFluff]

64bit is a no go as well?! Blah. It's not a "production environment" either... mmm, I mean, you make it sound "serious" or something *chuckles*

I just want to encode fast... Shit... That's all... Maybe I should run 2-4 64 bits avisynth?

If there existed a completely single-threaded 64-bit version, that'd at least have the potential to be stable enough for actually getting shit done (that's what I mean by "production environment"). Unfortunately, there is no such version, and using 64-bit also severely limits the amount of available plugins.

Just stick with Ye Olde 32-bit 2.5.8. If it was good enough for your grandfather, it should be good enough for you, and if you have to use so many filters that you run out of memory, the source was probably so bad that it wasn't worth encoding anyway.

Remember this, kids: trying to add multithreading to a huge software project that was written without a single thought of thread-safety in mind is madness and a recipe for an eternity of crashing. If said software project also loads and uses many third-party plugins that ALSO were written without a single thought of thread-safety in mind, you might as well kill yourself and end up in Hell already, because that's probably going to be more pleasant than what you're going to end up with.

[DarkT]

If there existed a completely single-threaded 64-bit version that'd at least have the potential to be stable enough for actually getting shit done (that's what I mean by "production environment"). Unfortunately, there is no such version, and using 64-bit also severely limits the amount of available plugins.

Dunno - I saw plenty people posting nice gains in speeds using MT ver and no stability problems. *sighs* I suppose I'll just have to try it out for myself if nobody else has anything helpful to say PRO one of teh choices... *sighs* ah well... Thanks for hte input thus far guys ;).

[TheFluff]

Dunno - I saw plenty people posting nice gains in speeds using MT ver and no stability problems.

And there are also plenty of people complaining about stuff crashing all the time. It's a multithreaded version of a non-threadsafe application, which in plain English means it may work just fine ten times in a row or crash ten times in a row, depending on factors such as the phase of the moon, your hair color, cosmic radiation levels and whether you sacrificed a goat before using the application or not.

edit: it might work if you only use it in single-thread mode, but honestly, avs-mt is just so buggy that you're not likely to notice much of a difference in stability anyway...

[SubJunk]

For me the most stable versions are SET's 2.6 builds. Every version is stable for me without multithreading, but using multithreading I have found 2.6 to crash less than 2.5.8.
It seems to be different for everyone but that's how it is for me :)

[Groucho2004]

Dunno - I saw plenty people posting nice gains in speeds using MT ver and no stability problems.

I could never get the MT versions to work properly. Some people have no problems at all.
There are a shitload of variables involved - complexity of the script, which filters are used (even the version of the filter can be crucial), in which order the filters are used, number of threads - should I go on?

All you can do is try for yourself.

[SubJunk]

The trick for MT stability for me was SetMemoryMax. Setting that to between 600-800 fixed crashes for me.

[DarkT]

Wait, so if you aren't using 2.6 for MT, what are the benefits then of 2.6 over 2.5.8?

[TheFluff]

The trick for MT stability for me was SetMemoryMax. Setting that to between 600-800 fixed crashes for me.

The operative phrase here being "for me". Since the entire thing is basically thread-unsafe, poking at anything that might change the way your OS schedules threads may also change the application's behavior and crashiness/non-crashiness. This is of course entirely impossible to predict and depends on so many factors (including things such as your OS version and your hardware configuration) that it's essentially meaningless to try to replicate.

[TheFluff]

Wait, so if you aren't using 2.6 for MT, what are the benefits then of 2.6 over 2.5.8?

It has a few new colorspaces. That's basically the only reason to use it right now.

[Groucho2004]

I have found 2.6 to crash less than 2.5.8.
I have seen statements like this about MT Avisynth several times but it still seems bizarre to me.
It's like hearing something like "I have a car that only breaks down once a week instead of every other day."

[DarkT]

I don't get it. What's good about moare colorspaces? You mean that yv12/yuy/rgb/whatever thingies? If you encode to h264, ain't you bounf to yv12 at the end anywya?

[TheFluff]

I don't get it. What's good about moare colorspaces? You mean that yv12/yuy/rgb/whatever thingies? If you encode to h264, ain't you bounf to yv12 at the end anywya?

2.6 supports YUV 4:4:4 which is like YV12 but without the chroma subsampling. x264 does support encoding that these days, too. Unfortunately, almost nobody actually uses 4:4:4, and the thing people actually do use (high bitdepth YUV, such as 10-bit YV12) is not supported.

[SubJunk]

Wait, so if you aren't using 2.6 for MT, what are the benefits then of 2.6 over 2.5.8?Official changelog between 2.6 and 2.5.8 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/)

[DarkT]

2.6 supports YUV 4:4:4 which is like YV12 but without the chroma subsampling. x264 does support encoding that these days, too.

What's it good for? Does it take care of the color banding or something? Does it require more bitrate? More encoding time?

[SubJunk]

I have seen statements like this about MT Avisynth several times but it still seems bizarre to me.
It's like hearing something like "I have a car that only breaks down once a week instead of every other day."No, I run encoding every day and it never, ever, ever crashes.
The only exception to that statement was 2011.07.19 caused crashing but that was fixed with 2011.09.13

[TheFluff]

What's it good for? Does it take care of the color banding or something? Does it require more bitrate? More encoding time?

It has full chroma resolution. It does not really solve problems with banding the way high bitdepth does, but it does provide "sharper" colors, I guess. It requires a lot more bitrate, takes a lot longer to encode and has quite bad decoder support still.

[Groucho2004]

It has a few new colorspaces. That's basically the only reason to use it right now.

Also, the resizers are much faster (at least on more recent CPUs).

[TheFluff]

Also, the resizers are much faster (at least on more recent CPUs).

That's cool, I suppose, but I've never really felt I've been bottlenecked on the speed of a resizer...

[junh1024]

I use MT all the time. I found 2.6 may be faster, but more unstable than 2.58.

With 2.58, I don't need to use setmemorymax. With 2.6, I baisically need to use setmemorymax(768) all the time.

Also, I only enclose the bottlenecks in my script, like fft3d, hqdering, or mdegrain 2 in MT(""" """)

[DarkT]

I use MT all the time. I found 2.6 may be faster, but more unstable than 2.58.

With 2.58, I don't need to use setmemorymax. With 2.6, I baisically need to use setmemorymax(768) all the time.

Also, I only enclose the bottlenecks in my script, like fft3d, hqdering, or mdegrain 2 in MT(""" """)

So... you are pro using 2.5.8 mt- in 32bit mode I am guessing? or 64?

[Groucho2004]

and if you have to use so many filters that you run out of memory, the source was probably so bad that it wasn't worth encoding anyway.
Good point.

[junh1024]

I usin 2.6 on Windows 7 Professional 32bit.

[DarkT]

Good point.

I wanted to use 64 bits coz I saw that on set's page, where he links to many filters, like, masktools works 25% faster or something, I figured, that's extra speed gains...

Infact, I'd rather use 32 bits, because there's more filters... Some of my favourite filters, no 64bit version :(

[TheFluff]

I use MT all the time. I found 2.6 may be faster, but more unstable than 2.58.

With 2.58, I don't need to use setmemorymax. With 2.6, I baisically need to use setmemorymax(768) all the time.

Also, I only enclose the bottlenecks in my script, like fft3d, hqdering, or mdegrain 2 in MT(""" """)

Do I really have to quote myself from the bottom of last page? Let me try one last time:

It is basically meaningless to make any statements about the relative stability of different multithreaded Avisynth variants (this includes the MT() filter).
A script and environment that is rock solid for one user may crash every time for another, due to the inherent nondeterministic behavior of using a non-threadsafe application in multithreaded mode. There are simply way too many variables that can affect how the application behaves in different scenarios to make any reliable predictions about what might crash and what might not.

[DarkT]

If many people get it to work consistantly... or semi consistantly... I'd say that puts your idea of why it sux outta business tbh...

[SubJunk]

TheFluff, we're just talking about our experiences. If it's so upsetting for you to "let" us talk to eachother then just go away, I assure you no one will care either way.

[TheFluff]

If many people get it to work consistantly... or semi consistantly... I'd say that puts your idea of why it sux outta business tbh...

But you're not asking many people. You're asking two people, and their findings are different.

[DarkT]

i am asking many people. As many as read this particular page. Out of those who do, and chose to reply, I'd say the percentage is quite high :). Nattttttttturally, this ain't no poll - which I think is actualyl quite a good idea... To make a thread where people would contribute their experience with MT... Hmmm...

Edit:

P.s. Greetings to all our friends at DarkHold ;).

[-Vit-]

I know of many people who can basically use MT 24/7 without problem. The recent fixes by SEt have made a marked difference (thanks!). Given that SEt is actively working on this, MT users should start with his latest 2.6 MT from this thread as well as plugins recompiled with his fixes. People overlook this last point: some of the buggy avisynth code is embedded in every plugin, so they need to be recompiled with fixes. A couple of plugin authors have done this, but the only other source for these plugins I know is my own collection of modded plugins for QTGMC (http://www.mediafire.com/?mfs7bp2rprbhp22).

Worth noting that some "threading" crashes are actually just out-of-memory conditions, what with all the threads sharing a 32-bit 2Gb address space. Can't just throw 8 threads at any script and expect it to work, then blame "threading" if it runs out of memory. Use less threads to fix, or maybe SetMemoryMax if you understand what it does. Unfortunately, 64-bit avisynth is truly problematic as there is no active development - no fixes coming there....

Splitting the encode into chunks and running each in a different process works well, but doesn't quite have the same performance and uses up much memory per thread. But interestingly the very best performance, especially for complex scripts+HD is to use this kind of splitting and MT scripts at the same time (e.g. split encode into 4 processes, each running a 4-thread MT). Best use of both CPU and memory (>2Gb). I'm finding this is the best way to use QTGMC + 16-bit processing on HD (and it's not true to say that complex scripts imply you are working with a poor source, the most complex part of QTGMC is source match, designed to precisely capture quality sources. 16-bit processing similar).

[SEt]

-Vit- pretty much summed it all. Except memory limit for 32-bit application is more: 4Gb on x64 OS and can be 3GB on 32-bit OS.

TheFluff, please stop spreading false information.

First of all MT avisynth is not about running non-threadsafe application in multithread mode - it's about making avisynth into threadsafe application. And it's definitely possible. The worst parts here are actually not threading itself, but cache inefficiency and initial design flaw of compiling part of avisynth into every plugin, so plugins that were built with old headers have to be recompiled.

Second: MT avisynth in non-MT mode is not any less stable than non-MT avisynth (the only difference I can remember is MT avisynth requires you to add brackets on function calls while non-MT forgives that error). If you have example where official avisynth 2.6.0 Alpha3 works but my build is not - do post it.


About relation to 2.5.8 MT 32 and 64 bit versions. They are definitely less stable than 2.6. The reason is simple: they are based on old sources. There were many MT problems found and resolved (in 2.6) since then, but no one backported the fixes to 2.5.8.

[asarian]

I could never get the MT versions to work properly. Some people have no problems at all.

For me, the sweet-spot is at 2.5.8, 32-bit, with a script as follows (as example):

SetMTMode(5,4)

FFVideoSource("f:\jobs\test.mkv")

SetMTMode(3)

Crop(0, 140, 0, -140)

MCTemporalDenoise(settings="medium", stabilize=true)
GradFun2DBmod(thr=1.4,thrC=1.0,mode=0,str=1.2,strC=0.0,temp=50,adapt=64,mask=false,show=false)

Not the absolute fastest way, but rock stable! The MT"" call is a no go for me: 7/10 times the process crashes somewhere (as luck would have it, usually when the job is 98% done).

The 64-bit AviSynth MT builds are a nightmare for me: extreme memory leaks, and almost instant crashes (if it hangs in there for more than 5 mins, it's much). Kudos if you got it to work for you, but I gave up on it.

I haven't tried 2.6 yet (is it even downwards compatible?).

[TheFluff]

Second: MT avisynth in non-MT mode is not any less stable than non-MT avisynth
About relation to 2.5.8 MT 32 and 64 bit versions. They are definitely less stable than 2.6.

these two statements seem to be contradictory

Furthermore, the problem with MT is not limited to the non-threadsafeness of the entire thing; it's also a matter of introducing a whole lot of new and interesting bugs while in the process of poking at basically everything in the entire application.

[asarian]

these two statements seem to be contradictory

How so?

Originally Posted by SEt
Second: MT avisynth in non-MT mode is not any less stable than non-MT avisynth

All this says is, that if you use MT AviSynth in a single-threaded manner, it will be no more unstable than its non-MT counterpart (which is true).

Originally Posted by SEt
About relation to 2.5.8 MT 32 and 64 bit versions. They are definitely less stable than 2.6.

And this just says both 32- and 64-bit versions of 2.5.8 MT are less stable than their 2.6 counterparts.

I don't see the contradictory information.

[DarkT]

*shrugs* If we take the testimonies of some of the posters, regarding consistently working without crashes with MT, then it is certainly a worthy try to see if person X can be one of such lucky ones. You could argue about what's better, or what works more consistently - but for me? The fact that SOME people can get it to work Consistently, is quite enought as a green light to go ahead and see if I can be one of the chosen lucky ones *grins*.

Anyway, thanks for the help guys, I think I am pretty much closed on the direction I'm going to try and go in ;).

I think that there needs to be a "come and test avisynth 2.6a3 by Set" thread, where people could give more feedback about what they try and what works and what not... BAsically, right now, some might try it coz it's there, but I think perhaps more should be encouraged to try it... Perhapes it could speed up the discovery of whatever bugs there are, etc... I dunno.

Anyyyyway - thanks for the info guys ;). I'll open a thread with my own experience once I get on it to let you all know how it went.

[SEt]

Furthermore, the problem with MT is not limited to the non-threadsafeness of the entire thing; it's also a matter of introducing a whole lot of new and interesting bugs while in the process of poking at basically everything in the entire application.
How about any proof for any of your claims?

DarkT, this is actually the thread you are speaking about. But I agree that there is not enough information for regular people to understand what is going on. MT avisynth now is not about "are you lucky enough to run it?" but rather "do you understand enough to use it correctly" (though luck does help ^_^). I'll try to add some information to first post.

[DarkT]

DarkT, this is actually the thread you are speaking about. But I agree that there is not enough information for regular people to understand what is going on. MT avisynth now is not about "are you lucky enough to run it?" but rather "do you understand enough to use it correctly" (though luck does help ^_^). I'll try to add some information to first post.

Thing is, this thread is in Avisynth Development... I see "development" I run for the hills *Grins* I don't want nuclear testing done on MY computer... *grins* ya know?

Basically, If you could JUST change name from alpha to beta maybe? *grins* or RC? *grins*

Some more info would be GREATLY appritiated... Like what the numbers mean in the SetMTMode or whatever the command meant... I tried to find that info, couldn't though, but I did get some help from one of the posters in this thread, he had sent me a cool beginner script which I will be trying out soon.

Anyway, some examples would also help, like, filter X needs this, and filter Y needs that... You know? Because... To get the average "noob"(me) involved, you do need to make things... Ummm simpler/easier ;). And I think there's a great value in getting more people involved, in terms of feedback, ya know? You basically need more guinea pigs :).

[SEt]

Edited first post. Something else should be mentioned there?

Removed frightening words "alpha" etc. ^_^ Not sure if it should be moved to "Avisynth usage" forum - I'd like to have here more constructive replays than "It doesn't work for me!!" (being here doesn't completely help, though).

[-Vit-]

It would be good to have a master list of plugins that are known to use your fixed header file (given that not many people can/will check the source code).
Then encourage people to recompile and post any other plugins with the new avisynth.h header onto this thread.

[SEt]

I'm not going to maintain such list. But I can link to other thread if someone is willing to compile and update the list. ;)

[Gavino]

Second: MT avisynth in non-MT mode is not any less stable than non-MT avisynth (the only difference I can remember is MT avisynth requires you to add brackets on function calls while non-MT forgives that error).
Omitting the brackets in a function call is not an error, eg from http://avisynth.org/mediawiki/Grammar:
If no arguments are being passed to the function, you can also make the function call without parentheses, e.g. FilterName. The primary reason for this is to retain compatibility with old scripts. However, it's sometimes convenient to leave off the parentheses when there's no possibility of confusion.

MT Avisynth will likely crash if you do this (see this post), and even when running single-threaded it will fail to add a cache to the function call, hitting performance. Could this problem not be fixed (or at least produce a compile-time error)?

As a separate point, from the first post of this thread:If you are using it with ffdshow for realtime processing - at the very end add
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

Won't GetMTMode(false) always return 1 following SetMTMode(1) ?
Or is the idea to detect the case where you are running single-threaded (no earlier SetMTMode in the script)? But in that case you could just leave out the extra code. :confused:

[SEt]

I'm a C programmer and when calling a function brackets are required in my book (this also improves readability as you don't need to guess each time is it a variable or function call). Compatibility with some abstract old scripts is not a good reason - correcting scripts is trivial. As for compilation error - maybe, not sure I want to touch the parsing code.

It's very clever code actually. If you rem first SetMTMode in script the rest are automatically invalidated (being after ffdshow_source() call). So last line allows switching between MT and non-MT modes with changing just one line in the beginning of script.

[Gavino]

I'm a C programmer and when calling a function brackets are required in my book (this also improves readability as you don't need to guess each time is it a variable or function call).
True, but the Avisynth language isn't C, and since the language spec permits omitting brackets, this must be regarded as a deficiency in MT Avisynth, especially when it causes a crash whose origin is far from obvious to the user.

[SEt]

I agree that it should not result in undefined behavior, but I rather forbid it than allow for the stated readability improvement.

[Gser]

All
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last
does for me in FFDShow is crash it. It works fine without it though.

[cweb]

The trick for MT stability for me was SetMemoryMax. Setting that to between 600-800 fixed crashes for me.

I never had problems and I've had that line in my scripts for quite a while.. hmmm, could be why my MT was always stable..

[levi]

I disagree with the unstable categorization of MT. Once you get a script working, it's not going to stop working or give different results. That would be unstable. Getting everything set up correctly can be challenging, but once you do it will work fine and continue to work fine.

[DarkT]

Been trying for an hour or two now to get the thing installed. It won't go.
I have windows 7 64 bits on.
I had 2.5.8 installed, and on top of that the Set version which was MT installed. It worked. I put the avisynth.dll in syswow64, and then I got in virtualDub 64bits an error: AviImport Filter error: (unknown) (80040154).
I uninstalled avisynth, and used the uninstaller provided by the Set version. I rebooted.
I installed avisynth 2.5.8 official. Checked that it works, it did(using AVSPmod - 32bit program, in the script, at this point in time I was using 32 bit directshowsource to load the video - that's all there was). The I have downloaded the 2.6 MT version. I've placed it in syswow64 dir. I have again checked with AVSPMod - using 32bit directshowsource that all was working, it did. I did version() and it said 2.6 or something like that. It was no longer the 2.5.8 ver. Then I have modified the script to load DirectShowSource.dll which came with the modified Set version of avisynth - the DSS which is 64bits. VDub64 throws that error. Then I tried the AVSS64.dll, and DSS2() as a loading command. nothing, no matter what I write in the script, VDub64 dies. AND - now AVSPMod won't load also... perhapes coz I deleted the DirectShowSource.dll(32bit) from the plugins folder.

Anyway, I also checked that MSVCRT71 and the MSCVRPT or whatever are all in place, they weren't but I got them and put them where they were needed.

It still won't work ;(. Ideas?

[um3k]

Simple, you can't use 64 bit plugins with 32 bit avisynth. Stick to the 32 bit plugins if you're using 2.6.

[DarkT]

Simple, you can't use 64 bit plugins with 32 bit avisynth. Stick to the 32 bit plugins if you're using 2.6.

Wait... Wait... so this 2.6 MT version of set... it's 32bits?! Damn... I though it's 64bits >.< *sighs* that would indeed explain everything... *sighs* Ah well, this is even better *Grins* no need to torment myself now with "nice that you got MT working... BUT... if it were MT AND 64bit, it would prolly be even FASTER!!!" *chuckles*

Edit:

I am encoding as we speak... wow... Jsut... freaking... WOW... I did NOT expect that...

The script:

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\nnedi.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\addgrainc.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\TDEINT.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\TMM.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\TIVTC.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\mt_masktools.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\removegrainsse2.dll")
Import("C:\Program Files (x86)\AviSynth 2.5\EXTRA\LimitedSharpenFaster.avs")
Import("C:\Program Files (x86)\AviSynth 2.5\EXTRA\MCTemporalDenoise.v1.4.20.avsi")
Import("C:\Program Files (x86)\AviSynth 2.5\EXTRA\LSFmod.v1.9.avsi")
Import("C:\Program Files (x86)\AviSynth 2.5\EXTRA\GradFun2DBmod.v1.5.avsi")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\fft3dfilter.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\gradfun2db.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\RepairSSE2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\EXTRA\Yadifmod.dll")

SetMemoryMax(512)
SetMTMode(3)
AVISource("Lulz.avi").ConvertToYv12(interlaced=true)
SetMTMode(2)
FFT3DFilter(sigma=1.0, sharpen=0.3,interlaced=true)
Yadifmod(order=0, field=-1, mode=0, edeint=nnedi(field=-1))
LimitedSharpenFaster(strength=37)
MCTemporalDenoise()
Lanczos4Resize(872,480)
Crop(12,0,-12,-0)
Trim(1,66562)

Thus far - when I have tried it without MT it was encoding at 4fps... Now? 12 fps... It is THRICE as fast!!! 300% gain, WTF?! AMAZING... SET, MAKE ME A KID!!! *grins*

It did crash when I set memory to 768. Crashed each time I tried it.

It hadnt finished encoding yet, but it will in an hour or so, I'll report how it went.

[ryrynz]

Can't say I've had any major stability problems with 2.58MT, I run about six filters in realtime, I tested 2.6MT but found it to be considerably slower with my script even with using SetMTMode(1). I guess everybody's mileage will vary.
Will have to try limiting threads and see what happens, how does 2.6MT run compared to 2.58MT for you guys performance wise generally speaking?

[Mosfetov]

Some syntax works some do not.

Is it still possible to use mt() with current 2.6.0MT?
Every syntax resuilt in error "wrong avisynth version...".

[Zep]

Is it still possible to use mt() with current 2.6.0MT?
Every syntax resuilt in error "wrong avisynth version...".

if i recall correctly Set said no more support for mt(). just use the SetMTmode() calls

[SEt]

I'm not maintaining MT(), so it quite possible broken. MTMode is way to go.

[DarkT]

Got a problem with fft3dfilter and fftw.dll on MT on HD material.

Ok, if you look a few posts up, you can see I used fft3dfilter with MT mode 2, just fine, but it was on SD material

Now, I am trying to use it on HD material, and it's a no go, When I set it to MT mode 1 it does work, and it does help - without it it's at 2fps, with it it's at ~5fps.

I just wonder what's up.

I tried the same fft3dfilter line I used on teh SD material on the HD material... It's a no go... how strange... Any ideas? I'll try to re-run it on SD material, perhaps something in the environment changed, and it'd no longer be possible on SD as well, will edit later on.

edit:

"An exception occurred in module 'KERNELBASE'."

Crashed :( Gonna try and go with fft3d only.

Edit2:

IT finished the encoding, but the video is messed up, 1 second you see it, tthe next you see half the pic, etc etc... how weird..

[SEt]

Looks like crash due to memory usage. Read the first post.

Do not use mode 1 unless you know filter is designed for that mode. Otherwise it won't necessary crash but likely produce very wrong result like described.

[DarkT]

What's weird though is that fft3d on SD material works fine with mode 2, but on HD it insta-crashes... So weird... Meh, I'm running lagarith lossless 1st pass only for fft3d purposes... 25hours, and 100gb for it... *sighs* ah well...

[TheRyuu]

What's weird though is that fft3d on SD material works fine with mode 2, but on HD it insta-crashes...

A larger size frame taking up more memory? Who would've thunk it.

SetMemoryMax is your friend.
The thing with SetMTMode is that it seems mostly dependent on the amount of RAM that you can give it, which generally means (at least) SetMemoryMax(2048) for HD material for even remotely complicated scripts, which means you better have a 64-bit operating system which can give processes 4GB of address space, which means your program better have the LARGEADDRESSAWARE flag set.

Then after a bit of praying and a script which actually threads well, it just might work.

That being said I don't really like SetMTMode. What it all boils down to is that SetMTMode is a hack and shouldn't really be relied upon or expected to work in any capacity. If it works congrats, you got lucky, if it doesn't oh well and just move on. 64-bit avisynth is the same way, except that's way more hacky and a giant piece of shit, MTMode is at least a respectable attempt.

[SEt]

64-bit Avisynth is not 'hacky'. It has only one problem - no one maintains it.

SetMemoryMax is not as trivial as 'set to 2GB and you are done' - sometimes smaller values give better result than larger ones.

[TheRyuu]

64-bit Avisynth is not 'hacky'. It has only one problem - no one maintains it.

Several internal functions don't work and for a time it didn't even properly abide by the Windows x64 ABI (and I'm pretty sure the version people recommend to use doesn't properly abide by it). Sure does seem a little hacky to me.

Have you even looked at the msvc project files for x64? They have a huge amount of useless (optimization) settings turned on which give the impression whoever did it had little to no idea what they were doing.

SetMemoryMax is not as trivial as 'set to 2GB and you are done' - sometimes smaller values give better result than larger ones.

Well it was more of a guesstimate than anything else really, just based on playing around with it a little. 2GB does seem like a good starting point though at least for HD material. As soon as you start throwing temporal filters into the mix the need for a larger cache size seems to go up real quick.

I don't know how exactly avisynth (and MT related company) are doing their frame caching but if my SetMemoryMax value is too small it seems as though avisynth just chews up cpu cycles for nothing and bogs down to something extremely slow (further hurting avisynth-mt's credibility in the process). I don't really see how having too large of a frame cache could hurt performance. On a side note I guess the function name "SetMemoryMax" isn't exactly the best name for it since all it really equates to is "UseThisAmountOfMemory()", and doesn't actually define a maximum amount of memory which avisynth can chose to use up to as the name implies.

[-Vit-]

If you increase the memory for the frame cache then you reduce the memory available for the filters themselves. Some filters use little memory, but others allocate quite a lot. Setting a huge frame cache increases the chance of the filters running out of memory and crashing. SetMemoryMax is a misleading name - it really sets a memory balance between cache and free memory for filters. There is a sweet spot for any given script for SetMemoryMax, where you have reserved just enough for its caching needs and no more. I.e. you should SetMemoryMax to the smallest value that doesn't slow down processing.

Since MT processes several frames simultaneously its memory and caching demands are multiplied. MT is much more likely to run out of memory than non-MT given the 32-bit constraint of avisynth. Setting thread counts / SetMemoryMax values that just won't fit in 32-bit memory is a frequent cause of MT problems.

[TheRyuu]

Setting thread counts / SetMemoryMax values that just won't fit in 32-bit memory is a frequent cause of MT problems.

Both of which can be reduced by uses processes which have the LARGEADDRESSAWARE flag set and be running them on a 64-bit OS (yay 4GB per process!).

[SEt]

I wasn't talking about exact x64 Avisynth build but rather about x64 version of Avisynth in general - it's stalled project no one works on. Haven't looked at that x64 build so can't comment about it. Windows x64 ABI is plain retarded in part about saving xmm registers. As for msvc project settings - I see that all the time, got used to almost always recreating them myself, sigh.

As for memory consumption - I think it's too early to blame 32-bit address space. Current MT Avisynth cache wastes way more memory than required.

[-Vit-]

I think it's too early to blame 32-bit address space. Current MT Avisynth cache wastes way more memory than required.
Yes, I know what you mean. Running out of memory is the problem, but it shouldn't be. A 32-bit address space should be plenty for extreme HD processing. But avisynth caches the output of every single filter in your script (and the final output frame - unnecessary for encoding). But really only filter outputs that are accessed temporally (+ some subtle dependencies) need caching beyond the current frame, very few in the typical script. I analyzed QTGMC and it has maybe 10 intermediate frames that really need to be cached (per output frame), but 100s are actually considered for caching. I tried to use SetCacheHints to help reduce this, but at that time (2.58, haven't looked at the code recently) SetCacheHints seemed to have been rather hacked about and I had limited success.

[DarkT]

Hmm, I see I see... So what you guys are basically saying is that I should go FFT3DGPU? *grins*

[cattolicboy]

Hi SEt, do you think to implement the possibility to load LoadVirtualDubPlugin in the future?
At the moment seems not working, maybe someone knows some trick to load it...

[SEt]

I've never used such feature and can't comment about it. It looks like a request for official Avisynth: http://forum.doom9.org/showthread.php?t=149113

[debpk77]

Hi SEt, do you think to implement the possibility to load LoadVirtualDubPlugin in the future?
At the moment seems not working, maybe someone knows some trick to load it...

I've never used such feature and can't comment about it. It looks like a request for official Avisynth: http://forum.doom9.org/showthread.php?t=149113

SEt,
Is not a request for official avisynth...
I've tried it too and avisynth exits with the following code:
Traceback (most recent call last):
File "AvsP.pyo", line 6291, in OnSliderReleased
File "AvsP.pyo", line 8822, in ShowVideoFrame
File "AvsP.pyo", line 9256, in UpdateScriptAVI
File "pyavs.pyo", line 167, in __init__
File "avisynth.pyo", line 117, in Invoke
WindowsError: exception: access violation reading 0xA6446895

I'm using x64 version of windows on an intel 64 bit processor.
Its not a memory issue. I've tried various values for setmemorymax() - all the way up to 4096 and it gives the same error.

That means we cant access the vdub filters (*.vdf) from within avisynth. which is a pity..

grateful if someone can help...

[Youka]

AvsP has it's own problems, so it crashes if a plugin throws an error during filtering process and not just at initialization. Try it simply with MPC and look for an error message.

[zerowalker]

What should i do if i want to Encode with x264 10bit, and use a script that use Ditherpost() in the end?

I mean, i don´t want it to go from 16bit, down to 8bit, then to 10bit, can´t i ditherpost to 10bit?

Thanks:)

[cretindesalpes]

Instead of DitherPost(), use Dither_convey_yuv4xxp16_on_yvxx(). Check this section of the Dither manual for the encoding command line. If you want straight dithering to 10 bit from DitherPost, see this post (http://forum.doom9.org/showthread.php?p=1519194#post1519194).

[sugarkang]

I am confirming MT stable running QTGMC. As others have noted, the key to getting this to work right was setting SetMemoryMax. Once I set it to 512, no more rainbow glitch screens. I have Win 7 x64 and 16GB RAM installed, but parameters 1024 and up resulted in errors; I have not tried anything between 512-1024 yet.

Set to 512, the speed increase is roughly double that of regular Avisynth. Used to get 10-13FPS, but now getting about 22-26FPS on DV source 720x480.

Running Win7 x64 Ultimate. 2.58 x86 Avisynth was the base install; 2.6 x86 MT avisynth.dll copied to SysWOW64 and system32 (don't know which is redundant; conflicting install instructions). Core i5-2500k, OC'ed to 4.4Ghz, everything is running swimmingly.

Hope this data point helps. My exact script:

SetMemoryMax(512)
SetMTMode(5, 4)

AviSource( "M:\_ process\2_ cedocida\DV3.avi" )

ConvertToYV12(interlaced=true)
QTGMC( Preset="Slow" )

[Lighto]

I am confirming MT stable running QTGMC. As others have noted, the key to getting this to work right was setting SetMemoryMax. Once I set it to 512, no more rainbow glitch screens. I have Win 7 x64 and 16GB RAM installed, but parameters 1024 and up resulted in errors; I have not tried anything between 512-1024 yet.

Set to 512, the speed increase is roughly double that of regular Avisynth. Used to get 10-13FPS, but now getting about 22-26FPS on DV source 720x480.

Running Win7 x64 Ultimate. 2.58 x86 Avisynth was the base install; 2.6 x86 MT avisynth.dll copied to SysWOW64 and system32 (don't know which is redundant; conflicting install instructions). Core i5-2500k, OC'ed to 4.4Ghz, everything is running swimmingly.

Hope this data point helps. My exact script:

You are only required to replace the existing standard avisynth.dll in the SysWOW64 folder with the MT one in your case.
You are missing SetMTMode(2) before QTGMC() for your script, might want to double check your script with the first post in the QTGMC thread.

[Gavino]

You are missing SetMTMode(2) before QTGMC() for your script
Exactly - with script as written, QTGMC is run with MT mode 5, ie single threaded.

[sugarkang]

You are only required to replace the existing standard avisynth.dll in the SysWOW64 folder with the MT one in your case.
You are missing SetMTMode(2) before QTGMC() for your script, might want to double check your script with the first post in the QTGMC thread.

Damn. I thought I solved a problem. I'll retry, but every other combination resulted in random rainbow block frames.

[tormento]

SEt, is it compiled with the LARGEADDRESSAWARE flag? If not could you please provide one for testing?

[Chikuzen]

SEt, is it compiled with the LARGEADDRESSAWARE flag? If not could you please provide one for testing?

http://blogs.msdn.com/b/oldnewthing/archive/2010/09/22/10065933.aspx

[tormento]

Wow. Learning is a neverending job.

[jinkazuya]

I have a question. I am just wondering why the encoding process never fully uses all the cores of the CPU and the threads.

I set my MT like this

SetMTMode(2,8). I thought the encoding is gonna make use of the four cores along with the hyperthreading, but when I looked at the CPU usage, it was only 18% - 20%

[TheRyuu]

I have a question. I am just wondering why the encoding process never fully uses all the cores of the CPU and the threads.

I set my MT like this

SetMTMode(2,8). I thought the encoding is gonna make use of the four cores along with the hyperthreading, but when I looked at the CPU usage, it was only 18% - 20%

Depends what your script looks like. Certain things don't thread well and most stuff non-trivial (save QTGMC) presents various other problems (http://mod16.org/hurfdurf/?p=234) for MT avisynth.

[ryrynz]

I would try calling some different MT modes in your script and or removing some filters to find out where the problem lies.

[lansing]

am i missing something here, the mt.dll for avisynth 2.6 is not in the package file?

update: I was trying to multithread fft3dfilter, but the only usage i've found is through MT("....."), how do i do this?

[pbristow]

lansing: mt.dll (and the filters it provides - MT(), MTi(), etc. ) is not supported with Avisynth 2.6. The MT *modes* are supported, but as they are built into AVisynth, they don't require mt.dll .

[Atak_Snajpera]

AviSynth 2.6.0 MT installer -> http://www.mediafire.com/?6vq1i35kz9cqjl1

Installer source files -> http://www.mediafire.com/?g7ex29zb0c1k4xt

[lansing]

lansing: mt.dll (and the filters it provides - MT(), MTi(), etc. ) is not supported with Avisynth 2.6. The MT *modes* are supported, but as they are built into AVisynth, they don't require mt.dll .

thanks for the explanation. But how do I use mt with fft3dfilter? I use it with SetMTMode(2) on my AMD athlon 4 core, but still only 25% cpu usage

[Atak_Snajpera]

you can also try hqdn3d istead of ff3dfilter.

[SEt]

Looks like no one reads explanations in first post, ever...

[GMJCZP]

With this version of Avisynth yesterday I tried to load a plugin for VirtualDub with LoadVirtualDubPlugin the way I've always done and then VirtualDubMod crashes, what is that?

In 2.5.8 MT I could perfectly.
I'll be doing something wrong or need to install anything?

[GMJCZP]

Please, I need an answer!
I had to go back to version 2.5.8 MT. I can use there are the VirtualDub fliters.

[SubJunk]

Thanks a lot for these updates, SET. I find your builds are the best ones!
It seems that env->GetMTMode() is missing, is there a reason for this? I have a plugin that relies on that function

[GMJCZP]

Please, I need an answer!
I had to go back to version 2.5.8 MT. I can use there are the VirtualDub fliters.

Any comments or suggestions?

[pbristow]

With this version of Avisynth yesterday I tried to load a plugin for VirtualDub with LoadVirtualDubPlugin the way I've always done and then VirtualDubMod crashes, what is that?

In 2.5.8 MT I could perfectly.
I'll be doing something wrong or need to install anything?

Hi GMJCZP,

To get any answers, you'll need to supply a bit more information, such as what specific plugin you're trying to load and exatcly how (the simplest and best way to do this is to post the exact script you're using), what exact symptoms you get (e.g. any error messages that occur before the crash), what other plugins have you tried and did they behave the same way, etc. Otherwise, the only suggestion anyone can reasonably make is "investigate the problem".

Also, you need to post the question in the Usage forum, not here in the Development forum.

Good luck! :)

[GMJCZP]

Hi GMJCZP,

To get any answers, you'll need to supply a bit more information, such as what specific plugin you're trying to load and exatcly how (the simplest and best way to do this is to post the exact script you're using), what exact symptoms you get (e.g. any error messages that occur before the crash), what other plugins have you tried and did they behave the same way, etc. Otherwise, the only suggestion anyone can reasonably make is "investigate the problem".

Also, you need to post the question in the Usage forum, not here in the Development forum.

Good luck! :)

Sorry if use this thread.

The problem is straightforward: All plugin Virtualdub I try to carry this latest version of Avisynth, to boot, for example, VirtualDubMod, I get the error message that this program will close.

That's all.

[SEt]

Update:

1) Updated to CVS, so everyone can try new interfaces: http://forum.doom9.org/showthread.php?p=1567792#post1567792
2) Some bugfixes/improvements, mostly exceptions-related.
3) VirtualDub plugins now work again.
4) Changed compiler to VS2010 - something could break due to this.


SubJunk, it's not missing - just moved in tables due to 2.6 stuff. Rebuild your plugin with new headers and it should work fine.

[Boulder]

Thanks, I'll download and start using the new build right away.

[SubJunk]

Thanks a lot for the new release!
If I rebuild with the new headers is there a risk of 2.5 incompatibility? Do you think 2.6 will eventually require most 2.5.8 plugins to recompile?

[SEt]

SubJunk, since it uses MT functions it's already incompatible with regular Avisynth, it will be incompatible with 2.5.8 MT due to new placement of MT functions, but there is nothing bad in it - 2.5.8 shouldn't be used anyway. If MT functions are called conditionally - you can still build it and maintain compatibility with 2.5.
2.6 will likely support 2.5 plugins without changes, but I hope they'll be recompiled if just to remove the ancient bad code that is compiled into all plugins and the main reason of "instability" of MT Avisynth mode.

[SubJunk]

OK, thanks for the explanation :)

[GMJCZP]

Thanks a lot.

[ryrynz]

Yeah, this is very great news. Avisynth development moves at such a slow pace is great to see new revisions.

Everything's working well here with no stability issues. Performance might even be slightly higher judging from the quick test I did. Thanks to you, IanB and everyone else involved.

[SEt]

Oh, I forgot one minor thing in change log:

5) This version accepts brackets-less function calls like official Avisynth.

[SubJunk]

Working well for me too so far :)

[GMJCZP]

I tried to load the VirtualDub filter "MSUSmartSharpen", and although not hung up VirtualDubMod, I just could not carry it, gave me error, as if the configuration that before worked now does not work.

[tormento]

Newer revision works fine and solved some seeking problem too.

Thank you ;)

[hydra3333]

Fresh Win7-64 install, i7-3820 16Gb. Copied 2.6 over the top of tsp's 2.5.7, used VIT functions for QTGMC plus loaded a few other relevant ones for a vanilla QTGMC script with DGindex. Opened script into avs2yuv, and it crashed with no avisynth message. Put 2.5.7 back, backed out to use non-VIT functions in same script and presto, it worked.

In hindsight maybe because I left (only) tsp's "MT" DLLs in the plugins folder and they autoloaded ?

[SEt]

Minor update:

1) Some more VirtualDub plugins compatibility fixes.
2) Issue with Overlay and YV24 (http://forum.doom9.org/showthread.php?p=1567993#post1567993).


hydra3333, MT dlls are not supported. And as base you should start from 2.6 alpha or 2.5.8, not earlier.

[titlis]

Sorry but the latest mt build keep crashing upon loading avspmod.
Other builds work properly.

http://img841.imageshack.us/img841/9458/63379138.png

[SEt]

Can't reproduce.

Latest as 2012.04.03 or 2012.03.31?

[titlis]

Can't reproduce.

Latest as 2012.04.03 or 2012.03.31?

2012.04.03

I'm using AvsPmod 2.2.1

[cweb]

I'm getting a CUDA error and "Failed to create video decoder (100)" running dgdecnv with this latest build you have posted today.. I'm guessing it needs to be recompiled too. Or is there something else which can be done to my script?

[SEt]

I'm even more puzzled: dgdecnv (latest) works without problems for me and changes in build environment were quite minor.
You don't need any recompilation. Try to pinpoint what exactly causes crash: plugin? OS? or it crashes even without plugins with plain AviSource?

[cweb]

I'm even more puzzled: dgdecnv (latest) works without problems for me and changes in build environment were quite minor.
You don't need any recompilation. Try to pinpoint what exactly causes crash: plugin? OS? or it crashes even without plugins with plain AviSource?

So I checked that my script didn't load any other filters. Just a call to dgsource(). The error is returned by dgsource().
CUDA is working with other cuda test programs etc on my pc. I'm running win7 64-bit.

I'm using the latest dgdecnv too.
My source file is an MTS file which I just indexed with dgindexnv, so I can't use AviSource on it. Instead I used AviSource on another avi, and this works without problems. I'm using Virtualdub 1.9.11.
Tried reinstalling my dgdecnv and I get the same result ..

[cweb]

I just checked.. it works with the stock 2.6 release.

[cweb]

I just checked.. it works with the stock 2.6 release.
but not with your avisynth.dll.. at least for me and my 64-bit win7.

[SEt]

Well, I'm using Win7 x64 too (2008R2 actually), so it isn't OS at least.
Let's wait for someone with debugging skills for better crash information - you can use previous version for now, not much difference.

[cweb]

Well, I'm using Win7 x64 too (2008R2 actually), so it isn't OS at least.
Let's wait for someone with debugging skills for better crash information - you can use previous version for now, not much difference.
Just in case I wasn't too clear, as far as I'm aware it's not crashing. It's dgdecnv which gives the message and obviously there's no actual video, but the video itself is replaced with the message 'CUDA error' generated by dgdecnv...

[Atak_Snajpera]

Avisynth 2.6 MT installer (2012.04.03) -> http://www.mediafire.com/?7l0cbjpcd4av1wb
Installer source files -> http://www.mediafire.com/?zu8m4b5zbjmt08e

[kypec]

Avisynth 2.6 MT installer (2012.04.03) -> http://www.mediafire.com/?7l0cbjpcd4av1wb
Installer source files -> http://www.mediafire.com/?zu8m4b5zbjmt08e
Excellent contribution, Atak :thanks:
I was thinking to prepare some installer myself but had no time to get to it.:o

[GMJCZP]

Thanks Atak_Snajpera.

[SEt]

Atak_Snajpera, you don't need to put msvcp60.dll in installer - nothing uses that ancient <censored> except official avisynth.dll.

[Atak_Snajpera]

i didn't know that.

[cweb]

I solved the CUDA problem when using DGDecNV. Here's how.

As a reminder,
1. A dialog box comes up (DGSource) saying 'Failed to create video decoder (100)'.
2. 'CUDA error' is displayed instead of the video.

avisynth.dll is in c:\windows\syswow64

The stable avisynth and the 64 bit avisynth builds worked with dgdecnv without problems for me.
Script is a simple call to dgsource.


It turn out I had an old nvcuvid.dll in the avisynth plugins directory. Deleting this file solved the problem. I'm not aware how this build triggered the problem (the stable build didn't) but I'm glad I found the solution.

[RedDwarf1]

This new version won't work with AvsPmod 2.2.1 or 2.2.0 on my system, whereas the earlier version that I was using worked without problems. I get a CPP runtime library error. This application has requested the Runtime to terminate it in an unusual way.

That is with the plugins folder renamed so no usable plugins and a new copy of AvsPmod, so no scripts or old settings.

2012-03-31 is working okay which I wasn't using previously because I was still on an older version.

[SEt]

cweb, oh, I have an idea now.
Another change I forgot to mention is how plugin DLLs are loaded. Now if they have dependencies – dependencies are searched first in the same folder as loaded plugin DLL. Hopefully it will reduce amount of DLLs you have to place in system32, but as it's different to earlier behavior it can cause unexpected situations like yours.

RedDwarf1, AvsPmod 2.2.1 works ok for me. Need more information to debug things.
"This application has requested the Runtime to terminate it in an unusual way." means there is uncaught C++ exception somewhere.

[Anacletus]

With the last build i got the same error as titlis and RedDwarf1.

I'm on Windows XP SP3 32bit, AvsPmod 2.2.1 keeps crashing with a simple script with just an mpeg2source call.

The same happens wit MeGUI as soon as i try and load the same script. :confused:

[RedDwarf1]

cweb, oh, I have an idea now.
Another change I forgot to mention is how plugin DLLs are loaded. Now if they have dependencies – dependencies are searched first in the same folder as loaded plugin DLL. Hopefully it will reduce amount of DLLs you have to place in system32, but as it's different to earlier behavior it can cause unexpected situations like yours.

RedDwarf1, AvsPmod 2.2.1 works ok for me. Need more information to debug things.
"This application has requested the Runtime to terminate it in an unusual way." means there is uncaught C++ exception somewhere.
What info do you require?

With the last build i got the same error as titlis and RedDwarf1.

I'm on Windows XP SP3 32bit, AvsPmod 2.2.1 keeps crashing with a simple script with just an mpeg2source call.

The same happens wit MeGUI as soon as i try and load the same script. :confused:

No scripts at all when I tried it.

I'm using XP SP3 as well. I can try it on another windows install when I get a chance and reboot.

[Anacletus]

What info do you require?



No scripts at all when I tried it.

I'm using XP SP3 as well. I can try it on another windows install when I get a chance and reboot.
That's true.. avspmod crashs as soon as i click the executable. :sly:

[SEt]

To debug this I need a way to reproduce the error. Or at least location of unhandled exception thrown and stack trace, so someone with debugging skills is needed for second approach.
To pinpoint what is causing your problems start with clean system (you can use VM – it lakes few minutes to set up but very useful for many experiments) and gradually add what you have. I suspect stray DLL in unexpected location that is now loaded instead of expected DLL.

[Boulder]

I suspect stray DLL in unexpected location that is now loaded instead of expected DLL.Would Dependency Walker help with this one?

[SEt]

Unlikely – DLLs can be loaded in runtime.
But you can try list of all process DLLs (with paths of course) in Process Explorer and see if you can spot the difference of previous version and new at the crash point.

[LoRd_MuldeR]

Unlikely – DLLs can be loaded in runtime.

Dependency Walker has a "profiling" feature that can be used to track all the DLL's loaded at runtime too.

Other than that, one can also use VMMap (http://technet.microsoft.com/en-us/sysinternals/dd535533) to show all modules (DLL's) that a given processes has currently loaded...

[Overdrive80]

I will discuss my experience. If I use:

SetMemoryMax(512)
SetMTMode(3,4)
source_filter()
SetMTMode(2)
processing_filters()

Any program freezes, increasing the size of the ram but without result

If I use:

SetMemoryMax(512)
SetMTMode(4,4)
source_filter()
SetMTMode(2)
processing_filters()

I get this error: http://s7.postimage.org/q5llnwpbv/Set_MTMode_4_4.png

Using follow script, run fine.

SetMemoryMax(512)
SetMTMode(5,4)
source_filter()
SetMTMode(2)
processing_filters()

My system is win 7 sp1 x64 on GA-x58-ud5+intel i7 920+ 6gb ram

[Boulder]

I think you are supposed to use SetMTMode(5,x) before a source filter, so the last example is correct (and thus runs without errors).

[TheRyuu]

I think you are supposed to use SetMTMode(5,x) before a source filter, so the last example is correct (and thus runs without errors).

And even then last I checked using mode 5 is highly discouraged.

Mode 3 should be used instead for situations like that IIRC.

[Boulder]

Well, for example DGSource doesn't like SetMTMode(3) on my computer while it works fine with SetMTMode(5). Of course, decoding the source is the smallest thing in my case so it can well run singlethreaded.

[Anacletus]

To debug this I need a way to reproduce the error. Or at least location of unhandled exception thrown and stack trace, so someone with debugging skills is needed for second approach.
To pinpoint what is causing your problems start with clean system (you can use VM – it lakes few minutes to set up but very useful for many experiments) and gradually add what you have. I suspect stray DLL in unexpected location that is now loaded instead of expected DLL.

Hi SEt,

i installed a clean Windows XP Service Pack3 into an Oracle VirtualBox VM, installed official avisynth 2.58 and it was ok. Downloaded your last build of 2.6MT and i got the avsp crash again.

System config:
Oracle VirtualBox 4.1.14 r77440
Windows XP SP3 (with all the security patches at the time of writing)
AvsP.exe 2.0.2.0
Avisynth 2.5.8 + Avisynth 2.6MT (latest version)

I used Dependancy Walker's profiling tool, you can find the profiling log attached, the exception is at line 476 ;)

[SEt]

Found it! Grab the new version.
XP runtime was terminating us for no good reason – I've hacked the compiler a bit to be more XP-friendly. NT6 users are unaffected. No source changes since version 2012.04.03.

[Reel.Deel]

Thanks SEt, your latest version (2012.05.16) works fine. BTW I'm Using Windows XP SP3 (32 bit).

[Anacletus]

Found it! Grab the new version.

:thanks:

[RedDwarf1]

Found it! Grab the new version.
XP runtime was terminating us for no good reason – I've hacked the compiler a bit to be more XP-friendly. NT6 users are unaffected. No source changes since version 2012.04.03.

:thanks: The new one works fine for me as well.

[BugiBugBug]

SEt, I've searched through this threat on information about the MT() function.
I noticed a post you made where you state that the MT.dll is not supported.
Remarkably however, in the beginning of this thread, notably BigDid (http://forum.doom9.org/showthread.php?p=1338268#post1338268) stated he was able to use the latest MT0.7 dll with your AS2.6
Still, MT.dll does not work for me (AV complains "wrong avisynth version. Use avisynth 2.6 or greater or modified avisynth 2.5.6").

Am I correct in assuming that for instance MT("FluxSmoothST(7,7)",threads=2) cannot be used with any of your AviSynth MT builds?

And that the only possibility to use the MT() mode would mean having to use the older 2.5.7 build supplied with the MT.dll?

I'm a great fan of temporal denoisers, and I have perceived the SetMTmodes to limit their effectiveness. If I understand the Wiki correctly the MT() mode is the only true option for effective temporal filters. But this may of course be incorrect; I do not really understand all the differences between SetMTmode - maybe I missed something and the MT() mode is deprecated?

[SEt]

MT() is unsupported by me, though it's not impossible to update it to the current Avisynth 2.6 MT state.
And sure MT() is not your only option besides MTMode: look in the forum – there are other threading attempts like pipelining.

[ryrynz]

Am I correct in assuming that for instance MT("FluxSmoothST(7,7)",threads=2) cannot be used with any of your AviSynth MT builds?


SetMemoryMax(1024)
SetMTMode(3,2)
ffdshow_source()
SetMTMode(2)
FluxsmoothST(7,7)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

Basically taken from the front page. I use this within ffdshow, I use Fluxsmooth often and had zero issues with SEt's builds.

[SEt]

Never put source filters in mode 2 – you are creating multiple instances of it. Use either mode 3 or 5 for them.

[ryrynz]

Thanks for the tip, I'll edit the previous post.

[Boulder]

I'm a great fan of temporal denoisers, and I have perceived the SetMTmodes to limit their effectiveness.Actually using SetMTMode makes them work exactly like they work in single-threaded mode. A temporal denoiser works over a certain area in a single frame and processes multiple sequential frames for each single frame. Depending on the spatial radius and the overlap value, using MT() could lead to sub-optimal results.

[BugiBugBug]

Actually using SetMTMode makes them work exactly like they work in single-threaded mode. A temporal denoiser works over a certain area in a single frame and processes multiple sequential frames for each single frame. Depending on the spatial radius and the overlap value, using MT() could lead to sub-optimal results.
Thank you for this clarification; I was already wondering how that would work, since I've never had crashes or anything with FluxSmooth or DeGrainMedian using SetMTmode. That is not the reason of my concern.

As you are saying, the filter needs a sequence of sequential/subsequent frames to calculate whether it smooths something. This is also the reason why I understood the threading method of SetMTmode to be sub-optimal for this purpose, because in my endless naivity I assumed using this would mean the following:
thread 1 gets e.g. frame 1,3,5,7 and calculates the temporal pattern of an area on their sequence.
thread 2 gets e.g. frame 2,4,6,9 and calculates the temporal pattern of an area on their sequence.

But if I understand your explanation correctly, two threads are created in which the same frame is thus present (i.e. read) in thread 1 on t=1, and present in thread 2 as well, at t=2.
But the 'noise correction' is applied in thread 1 to frame n, and in thread 2 to frame n+1.


I apologise if I'm bringing things up again that have been explained already (given the fact that MT has been around for some years now), but I have been unable to fully apprehend its use and configuration despite of countless hours of searching and reading. It's these specific questions vs. explanations that keep fogging my understanding.


So this is what I've got now, just for clarification:

SetMTmode(3,0)
LoadPlugin("")
DGDecode_mpeg2source("C:\CT.d2v", info=3)
SetMTmode(2,0)
ColorMatrix(hints=true, threads=0)
trim(125500,126500)
FluxSmoothST(7,7)
crop(10, 10, -8, -14)
Undot()
Spline36Resize(720,576)
Undot()
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

[Boulder]

But if I understand your explanation correctly, two threads are created in which the same frame is thus present (i.e. read) in thread 1 on t=1, and present in thread 2 as well, at t=2.
But the 'noise correction' is applied in thread 1 to frame n, and in thread 2 to frame n+1.Yes. If I have understood the process correctly (=the threads are totally independent of each other) :D. The processing gets a nice boost from the Avisynth cache because the same frame could be needed by many threads and it could already be in the cache when it is requested by a thread. Then again, the cache used to be the nest of many problems in multithreading, but I think that SEt has worked out quite a few of them.

You should make sure that you really need Distributor() in your script. Many applications do not need it since they call it themselves.

[SEt]

That's not how it works. Simplified a bit, it works this way: let's look at certain filter in the script in MTMode – there are indeed 2 threads, but both of them have all source frames, next from one thread frames 0,2,4... are requested and from the other thread frames 1,3,5... If the filter handles non-sequential requests correctly – it'll work exactly as in non-MT mode, but if it doesn't – things will break (note that they will also break in non-MT mode when some filter reorders frames like SelectEven or Trim).

The end
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last
must be used only for certain cases like ffdshow processing, for plain Avisynth usage it must not be used. How to guess? If MTMode doesn't change your CPU utilization no matter how many threads you request, but adding Distributer helps – you need it, otherwise you don't.

[Boulder]

If the filter handles non-sequential requests correctly – it'll work exactly as in non-MT mode, but if it doesn't – things will break (note that they will also break in non-MT mode when some filter reorders frames like SelectEven or Trim).I think in this case you could use tsp's RequestLinear before the filter, am I right?

[SEt]

In theory – yes (but after the filer, not before), in practice – RequestLinear doesn't work here.

[BugiBugBug]

Thank you both for the information. I think the source of the misunderstanding lays in the filter sequence. I've looked at the Wiki once more, and in combination with your explanation, the problem is that an AVS script is written sequentially from source to finished output, while the actual way of functioning is the other way around. This is a different perspective, and requires a change of thinking.

Hence if I've got two frames and two threads, these are requested at the end of the filter chain, and thus also split first at the end of the filter chain. Within each thread, these frames work just as they would if there was one thread, as the filter works on one frame at the time, and can simply request from the cache(MT) above it any frames it needs to work on that particular frame.

The effectiveness of the filter is thus not affected if the filter can retrieve the frame sequence it requires. The only way MT could thus negatively influence the (quality of the) execution of a temporal filter is if (1) the sequence does not provide all the necessary frames, but more likely: (2) the frames that the filter retrieves from the preceding cache are not in the right order or are not sequential/missing some frames.

Problems would only appear if the cache preceding the temporal filter does not output frames their right sequence (meaning it just gives out an alternating sequence of frames, e.g. 1,3,5,7 to thread 1 and 2,4,6,8 to thread 2 - or even more chaotic combinations).
My guess is this is what primarily constitutes the differences between the SetMTmodes.

A truly spatial filter such as a resizer should, under that logic, function regardless of the mode because it does not matter which frame it gets. Important is that the sequence is kept in tact in the cache that follows the filter execution.

Once again, thank you for clearing this up for me. I hope this will be useful for anyone else not familiar with the subject.

On a side note, as already expected, the increase in speed on my machine (a 5300 Merom) was very small (about 0,1 fps on a typical 11-13fps using AVCHD device preset with -preset-medium). Naturally this is because the AVS script is very simple.
But I did use this script to fprofile my own x264 builds, because it is the predominant way I'll be encoding.

[SEt]

If "sequence does not provide all the necessary frames" it'll likely would just throw an error, not invent missing data.
All frames are explicitly numbered and requested by number: if you asked for frame n – you can't get some other frame.

[ajp_anton]

From RGB24, ConvertToY8 results in a slight shift to the right. Going first to YV12 and then to Y8 works.

[DVDBob]

How should i configure the mt settings for a AMD Phenom II X6 1055T???

So i can use all 6 cores.

[pbristow]

How should i configure the mt settings for a AMD Phenom II X6 1055T???

So i can use all 6 cores.

AH, here it is folks: The miracle moment. The moment when the baby stares at the five funny stick things poking out of his hand and asks "how do I use these?".

The bad news, DVDBob, is that there's no simple answer to that question. But the good news is that you will be learning lots of new answers to it every day, for the rest of your life. ;)

For a basic "get you started" template script, look at the top post in the following thread:
http://forum.doom9.org/showthread.php?p=1312666#post1312666

For further info, see this page, starting about halfway down (under "ed avisynth MT 2.5.7.5 ")
http://avisynth.org/mediawiki/MT

Have fun! :)

[Rat Killer]

Need a hand. MeGUI seems to have done some updates including DGindexNV and now when attempting to index a file DGIndexNV.exe gives the following error:

The procedure entry point cuStreamDestroy_v2 could not be located in the dynamic link library nvcuda.dll

I have an Nvidia NVS 4200M running on a Dell laptop under Windows XP if it matters. Nvidia driver version 268.83 which is the latest from Dell.

Thanks for any suggestions on how to get this working again.

[golagoda]

Need a hand. MeGUI seems to have done some updates including DGindexNV and now when attempting to index a file DGIndexNV.exe gives the following error:

The procedure entry point cuStreamDestroy_v2 could not be located in the dynamic link library nvcuda.dll

I have an Nvidia NVS 4200M running on a Dell laptop under Windows XP if it matters. Nvidia driver version 268.83 which is the latest from Dell.

Thanks for any suggestions on how to get this working again.
Uninstall that driver and try this one: http://www.nvidia.com/object/quadro-notebook-win7-winvista-64bit-296.70-whql-driver.html (used the nvidia drivers search)

[Rat Killer]

Thanks!

Updating to the version 295 driver fixed it up.

[Atak_Snajpera]

Avisynth 2.6 MT installer (2012.05.16) -> http://www.mediafire.com/?prfoy9wfj4gtnnw
Installer source files -> http://www.mediafire.com/?308aa5d3r4nszwz

[SubJunk]

Thanks!

[defalopii]

I have tried this Avisynth 2.6 MT
Replacing the old avisynth.dll with Avisynth 2.6 MT
But the result make me disappointed

Please see the screenshot

http://76.imagebam.com/download/MHh5ENPPOFkDGdaS6YkNdA/19534/195339596/MT1.JPG

http://60.imagebam.com/download/w9587gmmliRRCKuyzTF3xQ/19534/195339601/MT2.JPG

* My system is Dual AMD Opteron 6272 with Total 32 Cores (My campus server, used for math calculations)
* RAM 16GB
* I am using MeGUI 2112
* x264 v2164

Avisynth Script
SetMTMode(3)
AVISource("C:\Documents and Settings\Administrator\My Documents\Downloads\Video\Sample.548673.avi", audio=false).AssumeFPS(24000,1001)
SetMTMode(2)
#deinterlace
#crop
LanczosResize(608,320) # Lanczos (Sharp)
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\Convolution3DYV12.dll")
Convolution3D("movielq") # Heavy Noise

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\VSFilter.dll")
TextSub("C:\Documents and Settings\Administrator\My Documents\Downloads\Documents\Watermark\watermark.srt", 1)

x264 profile

program --preset fast --pass 2 --bitrate 5000 --stats ".stats" --deblock -1:-1 --b-adapt 2 --ref 3 --weightp 2 --qpmin 10 --qpmax 51 --chroma-qp-offset -2 --rc-lookahead 60 --merange 32 --me umh --direct auto --subme 9 --trellis 2 --psy-rd 0.00:0 --no-fast-pskip --output "output" "input"

My Home PC with i7 2600 (Only 4 cores) even 6x more faster encoding, same encoding profile, same Avisynth script, and same video source but with No Avisynth 2.6 MT

So guys, can you explain to me what is wrong ??

[SEt]

With so many cores you sure hitting 32-bit address space limits with default number of threads. Try manually specifying different number of used threads in first SetMTMode call. Next, pipe output of Avisynth to x264 (you can also use 64 bit x264 this way) to free some more address space.
And if some other Avisynth MT version worked better at your setup - do post in case we have regression here.

[Atak_Snajpera]

also don't forget to update x264 to r2200. btw why do use only fast profile on such beast????

[defalopii]

With so many cores you sure hitting 32-bit address space limits with default number of threads. Try manually specifying different number of used threads in first SetMTMode call. Next, pipe output of Avisynth to x264 (you can also use 64 bit x264 this way) to free some more address space.
And if some other Avisynth MT version worked better at your setup - do post in case we have regression here.

Sory i dont understand, i am very new with this :confused:
Please give me the complete sample script, what should i do with SetMTMode(3) ?? change it to 5 or anything else ??
and why there is two SetMTMode, before and after the video source ??

also don't forget to update x264 to r2200. btw why do use only fast profile on such beast????

will try to use that x264 r2200
yeah its modified fast profile. i am not sure with this but the result is better than slow profile

[Atak_Snajpera]

especially with disabled psy visual optimalization. Take my advise and stick to presets created by developers. your settings are not good.

[defalopii]

Because i can not make Avisynth 2.6 MT works, so tried to split the video into 8 parts and than encode it simultaneously.

What i used:
* Dual AMD Opteron 6272 (Total 32 Cores)
* Video Source 1080p (1920x1040)
* MeGUI 2112
* x264 r2200
* Avisynth v2.5.8 rev. 2

On 8 simultaneous encoding the 1st pass only take 50% of CPU Usage, and the 2nd pass take the makximum 100% of CPU usage

Here is the screenshot
http://70.imagebam.com/download/PBKayju-TosxhqUIxEZZAQ/19546/195454179/beast.JPG

Used very simple Avisynth Script.
DirectShowSource("C:\Documents and Settings\Administrator\My Documents\Downloads\Video\Sample.548612-defa.mkv", fps=23.976, audio=false, convertfps=true).AssumeFPS(24000,1001)
#deinterlace
#crop
#resize
#denoise

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\VSFilter.dll")
TextSub("C:\Documents and Settings\Administrator\My Documents\Downloads\Documents\Watermark\watermark.srt", 1)

I used this profile. I dont know what is the best x264 Profile, please tell me..
program --preset fast --pass 2 --bitrate 5000 --stats ".stats" --threads 16 --deblock -1:-1 --b-adapt 2 --ref 3 --weightp 2 --qpmin 10 --qpmax 51 --chroma-qp-offset -2 --rc-lookahead 60 --merange 32 --me umh --direct auto --subme 9 --trellis 2 --psy-rd 0.00:0 --no-fast-pskip --output "output" "input"

So..what do You think about this ??
I hope i can make Avisynth 2.6 MT works to optimizing the all 32 cores, but i dont know how, will keep trying. Any suggestion please tell me very detail and clearly bcoz i am very new with this

[SubJunk]

Just change the first line in the script from:

SetMTMode(3)

to:

SetMTMode(3, 32)

It's normal for SetMTMode to only use 50% of CPU on some hardware unless you specify the number of cores.

[defalopii]

Just change the first line in the script from:

SetMTMode(3)

to:

SetMTMode(3, 32)

It's normal for SetMTMode to only use 50% of CPU on some hardware unless you specify the number of cores.

Still not work, there is no different between using MT or not

[SubJunk]

That's a weird problem to have. Hopefully someone can help you.

[Boulder]

Does MeGUI need the Distributor() call?

[SubJunk]

Does MeGUI need the Distributor() call?I use MeGUI a lot and have never needed Distributor

[defalopii]

For masters who want to experiment with this monster regarding to the MeGUI, Avisynth and x264 optimizing on multicore system You can PM me, i will give You access to this system

[Gavino]

With so many cores you sure hitting 32-bit address space limits with default number of threads. Try manually specifying different number of used threads in first SetMTMode call.
Just change the first line in the script from:
SetMTMode(3)
to:
SetMTMode(3, 32)
What's the point of that? - it's just the same.
Since he has 32 cores, the default is to use 32 threads anyway.

SEt's advice was to use fewer threads, eg
SetMTMode(3, 8)

[SEt]

Yes, I was suggesting using smaller numbers like SetMTMode(3, 8).
Also, CPU usage is only a hint if you are doing something completely wrong or not – only speed matters in the end and best speed in certain situations doesn't come with 100% CPU usage.

[defalopii]

What's the point of that? - it's just the same.
Since he has 32 cores, the default is to use 32 threads anyway.

SEt's advice was to use fewer threads, eg
SetMTMode(3, 8)

The MT doesnt work. I've tried many configuration, from 1 to hundred value but still no different between using MT or not

The best way for me is split the video source using mkvmerge GUI into 8-20 parts than encode it simultaneously. This is awesome, i can encode a video 1080p (1920x1080) with total duration 1h 57mn only take not more than 2 hours using above x264 profile. And the CPU usage can reach from 60% to 100% on the 1st pass, more part means more CPU usage can be maximized

But splitting and re-merging that so many pieces of course annoying. Thats why i still want the developer of MeGUI, Avisynth 2.6 MT or x264 can make it more easy-without manually split the video source into many parts-to maximize the multi core system

[Keiyakusha]

defalopii
Do note that having that much threads can degrade quality of your video. Because it is achieved by starting encoding of the next frame while previous is not yet finished (or something like that) or by using slices, but this also bad if you have so many of them. The difference is usually unnoticeable, but with this much threads you probably want to check this.
UPD: also, looking on your spitted files 60% load i recall that 1st pass never was very thread-efficient by itself so u should make sure that load during 2nd pass is maximized. Not sure if something about it was changed lately, i don't use 2-pass encodes for years now, only crf.

[Boulder]

Does the amount of utilized threads by the encoder executable change in Task Manager when you change the number of threads?

[SubJunk]

Since he has 32 cores, the default is to use 32 threads anyway.
Often the MTMode functions only use half the available threads, especially on Intels, so it's common for it to use 16 threads on a 32-thread CPU.
That's not this guy's problem though, I'm just replying to the question :)

[defalopii]

defalopii
Do note that having that much threads can degrade quality of your video. Because it is achieved by starting encoding of the next frame while previous is not yet finished (or something like that) or by using slices, but this also bad if you have so many of them. The difference is usually unnoticeable, but with this much threads you probably want to check this.

There is no quality degrade for the video result if You split it first into many parts than encde it simultaneously. I dont know if using MT, it probably degrade the quality.

Does the amount of utilized threads by the encoder executable change in Task Manager when you change the number of threads?

Yes its increase along with MT value. But if too much it will error "Process exits with error code: -1073741819 "

[pbristow]

Should this discussion be moved to the usage forum, perhaps? It doesn't seem to be a 2.6 MT development issue, more a general question of how to use Avisynth MT effectively.

[Keiyakusha]

There is no quality degrade for the video result if You split it first into many parts than encde it simultaneously. I dont know if using MT, it probably degrade the quality.
Sure, this is exactly what i mean. I tried to say that your way of splitting files to 8 or more parts may be better idea after all.


Does anyone knows if it possible that with this much threads x264 just reaches some point when previous frame doesn't have enough information to start encoding new frame so new thread is not created? Then maybe higher resolution video will use more threads... Makes any sense?

[Boulder]

Yes its increase along with MT value. But if too much it will error "Process exits with error code: -1073741819 "Have you tried to do something that is more CPU-demanding than a simple resize and Convolution3D at low resolution?

[defalopii]

Have you tried to do something that is more CPU-demanding than a simple resize and Convolution3D at low resolution?

yes i've tried it on 720x400, thread increase but the FPS just a little different with no MT. Even if using too high value its become slower

[Overdrive80]

The MT doesnt work. I've tried many configuration, from 1 to hundred value but still no different between using MT or not



You can try SetMTMode(5, 8), with my cpu i have problems too using MT in mode 3. Intel core i7

[defalopii]

You can try SetMTMode(5, 8), with my cpu i have problems too using MT in mode 3. Intel core i7

Only got about 70 FPS 1st pass on 720x400 videos, still same with No MT/another MT value arround 65-70 FPS, no significant increase

[SEt]

If SetMTMode doesn't work – you are doing something wrong. I can't guarantee that 32 threads will work flawlessly (never tested such case), but something around 8 definitely works well. And I'm talking about Avisynth speed, not something like MeGUI to x264.

There is no quality degradation with SetMTMode. Either filters are MTMode-friendly and you will get exactly the same result as in non-MTMode, or you'll get crash, glitches, whatever but graceful quality degradation.

Often the MTMode functions only use half the available threads, especially on Intels
What? First time I hear such issue. How about making proper bug report?

[defalopii]

If SetMTMode doesn't work – you are doing something wrong. I can't guarantee that 32 threads will work flawlessly (never tested such case), but something around 8 definitely works well. And I'm talking about Avisynth speed, not something like MeGUI to x264.

Whats iwrong ?? how is the proper installation of Avisynth 2.6 MT ??
What i did, installed the Avisynth from here avisynth.org, than replace the avisynth.dll in the System32 folder with avisynth.dll from Avisynth 2.6 MT, thats it, is that wrong ??

Actually guys, how many percent increasing the FPS with or without Avisynth 2.6 MT ?? Is Avisynth 2.6 MT utilize the all cores up to arround 100% of CPU Usage ??

Do You ever trying like me splitting the videos into many parts and encode it simultaneously ?? than see how awesome it utilize the all core and CPU Usage and increasing the total encoding speed. Maybe Avisynth MT, or MeGUI or even x264 should try this methode, spliting the videos rather than playing with threads/frames

I dont know, am i still on my way.,,??
or sould move it to another sub-forum, there is so much, i am confused where must write this :confused:

[Keiyakusha]

There is no quality degradation with SetMTMode. Either filters are MTMode-friendly and you will get exactly the same result as in non-MTMode, or you'll get crash, glitches, whatever but graceful quality degradation.
It degrades on x264 level, not avisynth. Unless for some reason you use 32 threads for avisynth but only like 2 threads for x264.
As for me, I don't see the reason to use many threads in avisynth. Most of the time the actual encoding is a more CPU-intensive task than pre-processing. Of course if we use only good optimized filters, and our source is not some old self-recorded VHS that needs a lot of processing. But many "heavy" filters can have their own threads anyway.

[VideoFanatic]

I can't seem to get a speed improvement on my dual core PC over normal Avisynth:

I have Avisynth 2.5.8. I replaced the system32 avisynth file with the 2.6 MT file. I am using this script with Simple x264 Launcher to make an h264 file:

setmtmode(5,0)
Mpeg2Source("I:\file.d2v", CPU=6)
setmtmode(2,0)
DeGrainMedian(limitY=2, limitUV=3, mode=1, interlaced=true)
Crop(0,12,0,-12)
Tweak(Bright=0, Sat=1.0, Cont=0.9, Hue=10.0, Coring=False)
AddBorders(0, 12, 0, 12)

What am I doing wrong?

[Groucho2004]

I can't seem to get a speed improvement on my dual core PC over normal Avisynth

Have you tried to measure the speed of the script alone? You can do that with AVSMeter (http://forum.doom9.org/showthread.php?t=162155).

[VideoFanatic]

How do I use that?

[Bloax]

Drop your .avs over the .exe?

[VideoFanatic]

It reported the following:

Minimum: 9
Maximum: 66
Average: 37

with this script:

setmtmode(5,3)
Mpeg2Source("H:\New\z = Encode\Raw January 03 2000 Fixed.d2v", CPU=6)
setmtmode(2,0)
DeGrainMedian(limitY=2, limitUV=3, mode=1, interlaced=true)

It reported the following:

Minimum: 13
Maximum: 30
Average: 21

with this script:

Mpeg2Source("H:\New\z = Encode\Raw January 03 2000 Fixed.d2v", CPU=6)
DeGrainMedian(limitY=2, limitUV=3, mode=1, interlaced=true)

So is it the limit of the h264 encoding speed thats preventing me from getting faster encoding times or do I need more than a dual core PC?

[Atak_Snajpera]

is cpu usage at 100 percent?

[VideoFanatic]

Yes it is.

[Atak_Snajpera]

so here is your answer why you don't see speed improvement. encoding speed on dual core is too slow.

[SubJunk]

What? First time I hear such issue. How about making proper bug report?I don't know if it's an issue or by design because of Intel's Hyperthreading (maybe they don't want to support the hyperthreaded cores)

Avisynth 2.6 MT installer (2012.05.16) -> http://www.mediafire.com/?prfoy9wfj4gtnnw
Installer source files -> http://www.mediafire.com/?308aa5d3r4nszwzIf you make another version could you please make it set a unique version in the registry? It currently sets "2.6.0 MT" which is great but will be cool if it sets a different one next time so I can check against it (like "2.6.0 MT 2012.05.16" or something)

[SEt]

I have no idea what you are talking about. From Avisynth point of view hyperthreaded cores are as good as regular cores and there are no differences. I myself use hyperthreaded Intel CPU and never saw anything like that.
Note: as Avisynth is a dynamic library and not stand-alone process it inherits whatever CPU settings the host application set (like affinity) so such effects are possible but it's not Avisynth fault.

[SubJunk]

Sure, the thread-detection has always seemed weird. On my previous quad-core CPU I had to run SetMTMode(x,8) to get full CPU usage, even though it only had 4 cores/threads. It seems to detect my current CPU properly, though.
As a rule-of-thumb on AVSForum we usually recommend users enter 1.8* their core count into it (so an 8-core CPU would use SetMTMode(x,14), etc.). Some CPUs work ~80% faster with that value, others crash, in which case the user should enter the real number of cores.
I had always assumed that it was done on purpose by the AviSynth developers *shrugs*

[Atak_Snajpera]

it all depends what filters you use. When I was using mvtools for 50 fps -> 100 fps interpolation I also had to use SetMTMode(x,8 or 10) in order to achieve max speed/cpu usage on my Q6600@3Ghz. For less intensive filtering SetMTMode(x,4) was sufficient.

[SubJunk]

Yeah that could be it, since most of these times I was using mvtools2 or scripts that use it like QTGMC

[yup]

Sure, the thread-detection has always seemed weird. On my previous quad-core CPU I had to run SetMTMode(x,8) to get full CPU usage, even though it only had 4 cores/threads. It seems to detect my current CPU properly, though.
As a rule-of-thumb on AVSForum we usually recommend users enter 1.8* their core count into it (so an 8-core CPU would use SetMTMode(x,14), etc.). Some CPUs work ~80% faster with that value, others crash, in which case the user should enter the real number of cores.
I had always assumed that it was done on purpose by the AviSynth developers *shrugs*
Hi Subjunk!
I am also increase filtering speed on Q6600 1.5 times replace SetMTMode(x,3) to SetMTMode(x,7) load CPU increase from 40 to 60%, if increase up to SetMTMode(x,8) load CPU increase up to 100% but filtering speed drop.
Script contain QTGMC.
Interesting.
Subjunk! Thanks for trick.
yup.

[VideoFanatic]

I've replaced the avisynth.dll in the System 32 folder with the file from MT. However when I try to encode the video in Simple x264 Launcher it crashes and I get the following message "avs2yux_x86.exe has stopped working". Yet if I encode with HC Encoder I don't get any problems.

[VideoFanatic]

The following works.

setmtmode(5,3)
Mpeg2Source("L:\Raw 2001\01 Raw January 2001\Jan 8\Raw January 08 2001.d2v", CPU=6)
setmtmode(2,0)

However when I add the following to the bottom, HC Encoder encodes the video with a white glow around the edges of objects. It won't encode at all in Simple x264 Launcher and it crashes saying that "avs2yuv_x86.exe has stopped working".

McTemporalDenoise(settings="medium", interlaced=true)

[VEGITA]

I have similar problems with QTGMC, I can open the script in AvsP but when I load it in MeGUI I get a gray output in preview window and it just freezes after I close the preview window.
Script:

SetMemoryMax(512)
SetMTMode(3 )
LoadPlugin("D:\MeGUI_2028_x86\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\ohi04.d2v", info=3)
LoadPlugin("D:\MeGUI_2028_x86\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
SetMTMode(2)
QTGMC( Preset="Medium", SourceMatch=1, EdiThreads=1 )

[yup]

holygamer and VEGITA!
Your problem related to DGIndex.
At DGIndex demux to m2v Your VOB files.
MeGUI at tab tools have AVS script creator from source try ffmpegsource instead of DGDecode.
yup.

[Adub]

Yeah, if I remember correctly you want to be careful when calling a source function in a multithreaded fashion. Try loading your source with DGDecode and THEN loading SetMTMode().

[Groucho2004]

Try loading your source with DGDecode and THEN loading SetMTMode().
That would certainly solve the problems but might be pretty slow. :)

[phoenixxl]

Hello.

I am using avisynth with wine1.4 (current stable)

I write this to mention that the 3 versions of avisynth.dll made after 2011.09.13 do not work in wine.

Instead of trying to describe what is wrong i'll simply add 2 screenshots.

I would not think functionality on linux is the main concern for this dll , but i'm sure it's nice to be able to say it works everywhere. Unlike the original dll in 2.6 this mt one at least works.

anyway,

post 2011.09.13 ->
http://i.imgur.com/7EDgS.jpg


the dll from 2011.09.13 ->
http://i.imgur.com/hBcmD.jpg

The avs is nothing more than loading a sequence of images:


ImageSource("Mintgrow\%06d.ebmp", 0, 1231)


Friendly regards
Phoenixxl.

[Groucho2004]

I recall some problems with ImageSource() and devil.dll, you may have to update (http://sourceforge.net/projects/openil/files/DevIL%20Win32/).

[phoenixxl]

Nope. After replacing dll's it's still the same.

Thank you for suggesting it though

[Groucho2004]

Nope. After replacing dll's it's still the same.

Thank you for suggesting it though

The usual things:
- Does it happen with the "official" Avisynth (2.6 A3)?
- Did you try different MT modes?
- Post the entire script.

[phoenixxl]

That is the entire script. -> ImageSource("Mintgrow\%06d.ebmp", 0, 1231)
The "official" avisynth 2.6 Alpha 3 doesn't work at all on wine.
I am not using any mt modes.

The only difference between working and not working is the dlls from before 2011.09.13 work and those after 2011.09.13 don't.
The exact same setup on a windows machine works without any issue.

@Groucho If you have no hands on experience with using avisyth with wine , don't feel obliged to look into this any further. My message was meant as a note for SeT , nothing more. This isn't a general "request for assistance".


Since the 3 compiles after 2011.09.13 are significantly smaller something drastic in design terms probably happened at that point . Since the change generates no faults with avisynth running on windows it was probably considered valid.
At best with this post I am hoping SeT -or someone close to him involved with the development - takes the extra step of checking if the DLL works on wine before releasing the next version.

[Are_]

As far as I know "official" build does not work because wine does not bundle needed vcs6 dlls with it, if you manually install them it should work (I know you are not in the need neither in the urge, it's ofyi).

The difference in size is most likely, because beforehand it linked against something statically (packing it in avisynth.dll), and now it does it dynamically, and if you have errors because that, it may be wine's fault by doing something wrong.

I was not able to replicate your problem using 2012.05.16 dll and wine 1.5.8 (I created an image sequence with "ImageWriter("", type = "ebmp")" and then loaded it with "ImageSource("%06d.ebmp", 0, 200)").
I tested with wine 1.4 and I was able to replicate your results, so wine 1.4 is the one to blame.

[phoenixxl]

@Are_

Thank you for taking the time to check this.

For now I will probably be keeping to stable wine14 and use an older version of avisynth.dll. I'm already happy knowing that when 1.5 is stable the problem will be solved.

Friendly regards
Phoenixxl.

[SEt]

Indeed in recent versions build chain changed: from VS2005/2008 and static crt linkage to VS2010 and dynamic crt linkage to msvcrt.dll (XP level). I don't think there is anything wrong with avisynth.dll – probably it's wine to blame for incomplete/incorrect msvcrt.dll implementation.

[LoRd_MuldeR]

AFAIK, binaries that were compiled with VS2010 and that are using the DLL version of the Visual C++ Runtime ("/MD" switch) will depend on MSVCR100.DLL, not MSVCR.DLL. The latter (without a version number in the name) is part of the Windows operating system and many system programs (like e.g. Explorer.exe) make use of it. Also binaries compiled with MinGW/GCC use the MSVCR.DLL. The MSVCR100.DLL, on the other hand, is not part of the operating system. It's a VS2010 redistributable and any application that needs this DLL must install it! Fortunately, starting with VS2010, Microsoft made it possible again to simply put the MSVCR100.DLL into the same folder as the EXE file. The Visual C++ Runtime DLL's of VS2005 and VS2008 (MSVCR80.DLL and MSVCR90.DLL) would not work this way, because they were managed by "Windows Side-by-Side" (WinSxS) and therefore had to be installed using the Visual Studio 2005/2008 Redistributable installer program. It also has to be noted that, starting with VS2010, Microsoft has increased the minimum system version (in the binary's PE header) to "5.1", i.e. Windows XP. Trying to run such binaries on Windows 2000 (or even older) will result in "Not a valid Win32 executable" error message. The Visual C++ Runtime of VS2010 also makes use of two Win32 API functions un-available before Windows XP with Service-Pack 2! I have implemented a workaround (http://mulder.googlecode.com/svn/trunk/Utils/EncodePointerLib/README.txt) for this, but it can only work with the static Visual C++ Runtime.

As for Wine, I'm not sure whether it ships with a MSVCR.DLL, like a "real" Windows system does, or not. But for a binary compiled with VS2010 that shouldn't matter at all, as such application has to provide its own MSVCR100.DLL anyway...

(BTW: It might be possible that certain versions of Wine refuse to load binaries that need a minimum system version of 5.1 and/or have problems with the new Win32 API functions. It definitely does work with Ubuntu 12.04 though!)

[phoenixxl]

It definitely does work with Ubuntu 12.04 though!)

Try reading a sequence of ebmp's. Use wine 1.4

[SEt]

I know well what I'm talking about. It's linked exactly to msvcrt.dll, not msvcr100.dll or some other troublesome runtime dll. The change was made because this way has both advantages of reducing code size and not requiring some non-system dll.

[LoRd_MuldeR]

Try reading a sequence of ebmp's. Use wine 1.4

Well, all I was saying is that applications compiled with VS2010 and thus using MSVCR100.DLL generally do work under Ubuntu 12.04 + Wine (whatever version of Wine is bundled with Ubuntu 12.04).

I have checked this with my own applications. Still other random problems might pop up with other applications when running under Wine. For example I noticed that calling SetConsoleIcon() crashed my application under Wine :rolleyes:

[djonline]

When x64 2.6.0 will be ?

[SEt]

From me – likely never. Not anytime soon at least.

[tormento]

x64 is useless if no "modern" plugin is compiled, as MVTools2 from cretinesdesalpes and so.

[kypec]

From me – likely never. Not anytime soon at least.
I don't care about x64 Avisynth either but what about new x86 build that would include two recent Ian's bug fixes (http://forum.doom9.org/showthread.php?p=1585355#post1585355) :D
:thanks:

[ryrynz]

Those were only just added. Give the man some time! :P

[SEt]

I don't have access to by usual build environment now, so expect new build in around two weeks.
You can get all my code changes from first post and apply them to current cvs yourself if you can't wait – results won't differ much.

[SEt]

How about dropping WinXP/2003 support? I'm updating to VS2012 and by default it produces files that require minimum NT 6.0 (Vista/2008).

[mastrboy]

How about dropping WinXP/2003 support? I'm updating to VS2012 and by default it produces files that require minimum NT 6.0 (Vista/2008).

I don't mind, XP/2003 are ancient after all.

[ryrynz]

I'm for it also, compile with VS2012.

[forclip]

I'm still on XP.. I don't think that is a good idea to drop support for XP.

[Atak_Snajpera]

so it is your problem now. wake up it is 2012 time to upgrade to windows 7! set you have green light from as well.

[ryrynz]

I read there will be an update to VS2012 that will allow for XP support later this year.
New builds up until that time can lack XP support until the patch arrives and then perhaps you could make a build that has XP support, either by default or a separate build (just a special case if there's any drawback to having XP support by default)

[forclip]

so it is your problem now. wake up it is 2012 time to upgrade to windows 7!
Why I must pay for upgrading to Win7 if WinXP is enough for me and I'm satisfied with it?!

Also, quick googling gave me this links:
one (http://www.w3schools.com/browsers/browsers_os.asp)
two (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
- if this statistics is correct, not less than 25% of users still uses WinXP.

[Atak_Snajpera]

Why I must pay for upgrading to Win7 if WinXP is enough for me and I'm satisfied with it?!

Also, quick googling gave me this links:
one (http://www.w3schools.com/browsers/browsers_os.asp)
two (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
- if this statistics is correct, not less than 25% of users still uses WinXP.

the same could say user with windows 98... besides you can compile your own avisynth mt.

[Groucho2004]

Why I must pay for upgrading to Win7 if WinXP is enough for me and I'm satisfied with it?!
Just ignore this guy. His arrogant and childish attitude is becoming tiresome.

[forclip]

The same for you:
besides you can compile your own avisynth mt
that will only support Vista+. But for "mass production" I think that WinXP still should be supported. The fact that you already on Win7 doesn't mean that everyone around is also on Win7. So many people for one or another reasons is still on XP, why they must be forced to move to Win7?!

Sorry, don't want to discuss about it, just put my 5 cents.

[ryrynz]

I love it how when updates are made to programs that discontinue support for a sub section of users they suddenly "seem" to think that the program they're currently using just stops working.

You do realize you can still use what you're using right? Are you having any issues with the program? No? Then why do you need to upgrade?

Isn't this the very opinion you have of the OS you're running?

"I have no issues so I don't need to upgrade!" Hypocritical? You bet.

Everybody loves updating their apps, they're free and easy to update after all! but when it comes to the OS.. oh it's so much work and money to upgrade.

You're always going to have complaints from people with their heels planted firmly in the ground.

Do it anyway. :)

[Atak_Snajpera]

Just ignore this guy. His arrogant and childish attitude is becoming tiresome.

xp users must extinct. i don't care whether you like it or not. the same happened with win9x users and your whinning won't prevent that!

[SEt]

I'm using 'tweaked' Visual Studio, so it's not directly related to what it/will officially support but making NT 6.0 baseline would require way less hacks.
Actually I'm most worried about 2003(=WinXP 64) since it, unlike awful WinXP, is still reasonable OS to use for video processing. WinXP with its licensing limit of 4GB of address space is a joke here.
Also note that Avisynth is no way "mass product" ;).

As for the need to update Avisynth – as ryrynz mentioned, there is no real reason to update. Avisynth 2.6 is dead for quite some time now and changes are very minor, even the "new API" introduces nothing new.

About upgrading OS. New interface of VS2012 is bad, but new interface of Win8/Server2012 is plain unbearable. So, as much as I welcome kernel improvements, these OS are unusable right now. There are bad sides of Win7, but it is definitely useable.

[Groucho2004]

xp users must extinct. i don't care whether you like it or not.
I rest my case.

[kypec]

@SEt - do as you like, these are your builds and no one should be forcing you to make them this or that way. I don't mind leaving XP support at all, Win7 is so much better and I've been using it for more than 2 years now...

[StainlessS]

Dont worry guys, there will undoubtedly be yet another fork/build set for XP users, it will just have a name change.

[cretindesalpes]

I’m also in favor of keeping a WinXP support.

[Wilbert]

xp users must extinct. i don't care whether you like it or not. the same happened with win9x users and your whinning won't prevent that!
Perhaps that would be a valid point if using this was not necessary: http://forum.doom9.org/showthread.php?t=146910. I'm also running XP and won't upgrade as long as possible.

[pbristow]

My 2 groats: I'd prefer to see WinXP (or at least 2003) supported for a while longer, at least in the sense that we try to avoid making code changes that will only work with later versions... but that doesn't mean Set has to produce WinXP *builds* if he doesn't find it convenient to do so. What matters is that the Avisynth code moves forwards in power, performance and stability, and if having to mess up his build environment to provide backward-compatible builds is going to slow that development down, then it should not be required.

Set: Build things the way that's easiest for you to get your work done. There are plenty of people here who have the ability to re-build a given version of the code for XP, if there's enough demand for it.

(My 2nd/"backup" machine is still on XP, and rather than ever being upgraded to Win7 it's more likely to get replaced entirely someday... But in practice, unless my main machine goes bang/gets infected or I have a rush job on, I only do video processing stuff on Win7/64.)

[Sparktank]

I have 3 machines: WinXP (x86), Vista (x86), and Win7 (x64).

The other two machines are too old (and expensive) to upgrade, there's currently no driver support for them in Win7.

I use mostly WinXP for all my Avisynth needs.
I rarely used Win7 for Avisynth.
That is not to say that I won't in the future.

But keeping XP builds would be favourable.

[SEt]

As far as I can see in VS2012 there are no major portability problems with C part or runtime, but C++ part (strings) heavily uses NT6.0 WinAPI functions.

Wilbert, those tools are definitely unnecessary: all you need is to wipe 1 (2 for x64) registry key – and DirectShow will behave the same as on NT5.

[StainlessS]

SEt, you go the way you feel you have to, its not the right move but it's your call.
Nothing wrong with another fork, all the advantages of SEt's builds but with XP too.
Looking forward to it. :)

[SEt]

lol, I give up on VS2012 for now – it's unable to build Avisynth in release:
LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage

So, expect usual VS2010 build in some time.

[mastrboy]

That's too bad...
Btw, have you ever tried compiling it with intel's compiler?

[hajj_3]

Microsoft support for XP ends in April 8th 2014 so there will be no security fixes etc past then, so there's not much point in supporting XP anymore.

[pbristow]

lol, I give up on VS2012 for now – it's unable to build Avisynth in release

OK, I feel better about myself now... and the fact that I couldn't get anything bigger than "Hello world" to compile in VS2012 either! ;)

[detmek]

Microsoft support for XP ends in may 2014 so there will be no security fixes etc past then, so there's not much point in supporting XP anymore.
Well, certenly not after may 2014. Untill then...

[Wilbert]

Wilbert, those tools are definitely unnecessary: all you need is to wipe 1 (2 for x64) registry key – and DirectShow will behave the same as on NT5.
Great news! Which keys?

[Sparktank]

Microsoft support for XP ends in may 2014 so there will be no security fixes etc past then, so there's not much point in supporting XP anymore.

^this.

Well, certenly not after may 2014. Untill then...

^this.

[SEt]

Wilbert, clean the contents of these keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectShow\Preferred
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectShow\Preferred (obviously, x64 OS only)
Though you will need to give yourself the rights to do so first (permissions->take ownership->give yourself full control rights).

[Didée]

Do I vaguely remember reports that the thumbnail generation for video files in Windows explorer is negatively affected by this?

[Atak_Snajpera]

Do I vaguely remember reports that the thumbnail generation for video files in Windows explorer is negatively affected by this?

nope...

[SEt]

Finally an update.

Changes:
1) Merged with CVS.
2) Correct passing of float parameters discussed here (http://forum.doom9.org/showthread.php?t=164974).

[Boulder]

Thanks a lot!

By the way, have you looked at the cache changes made by the SVP team?

[mastrboy]

Finally an update.

Changes:
1) Merged with CVS.
2) Correct passing of float parameters discussed here (http://forum.doom9.org/showthread.php?t=164974).
:thanks:

Do you keep a changelog you could post?

[Reel.Deel]

Here's what chainik_svp wrote about the modified SVP Avisynth.
Also, here's the source (http://www.svp-team.com/files/gpl/avisynth-2.5.8-svp.zip) for the modified SVP Avisynth.

-Vit-
a major problem with HD is that we cannot run enough threads to use up the CPU before running out of memory

It was the first real problem we faced with SVP :) The current solution (modified Avisynth version) is good for SVP, may be it can be good for you too.
There're two mods in it:
1. distributor code is sometimes more effective (= needs less threads for the same processing speed for FRC)
2. sizes of internal caches between filters are limited by exact number of frames, not by global SetMemoryMax value and it's working great with linear video processing. For example one can use pel=4 with 1080p clip in MVTools with this mod.
So the total memory consumed depends on <number of filters>*<size of each cache>.

In case you're interested:
- global script value "svp_scheduler=true" turns on both mods, cache size is something like <num of threads>*2
- "svp_cache_fwd=<num_of_frames>" - set the exact cache size

And don't forget about "4gb patch" :)

[SEt]

mastrboy, no change log as changes are pretty much only bugfixes and nothing important happened for a long time.

Reel.Deel, I'll look into it when I have time, but probably there isn't much point hacking current cache implementation.

[the_weirdo]

Finally an update.

Changes:
1) Merged with CVS.
2) Correct passing of float parameters discussed here (http://forum.doom9.org/showthread.php?t=164974).

Thank you very much for the new build.
However, could you please provide an additional build without the change #2? Because currently, that change seems to break some existing scripts (and maybe some plugins too, I'm not sure).

EDIT: Sorry, the error might not caused by that change. But I don't know why after update this build, I get a lot of "access violation" messages with various plugins in existing functions, for example mt_masktools_26.dll and RemoveGrainSSE2.dll. Those scripts were worked fine with build 2012.05.16. I'm using Windows 7 64-bit.

[Boulder]

I also have the same issues with RemoveGrain_SSE2.dll. Switching back to the previous build fixes the problem.

[SEt]

Give me exact dlls and script that reproduce the error – I'm building RemoveGrain myself and don't have problems.

[Keiyakusha]

I noticed few of my scripts stopped working too... I haven't investigated but it seems to be related to avarpsharp2.

[Boulder]

I use the dlls from this package: http://forum.doom9.org/showpost.php?p=1568142&postcount=1126

I can reproduce it by loading the source and using SPresso().

function SPresso(clip clp, int "limit", int "bias", int "RGmode", int "limitC", int "biasC", int "RGmodeC", string "tune")
{
limit = default( limit, 2 )
limitC = default( limitC, 4 )
bias = default( bias, 25 )
biasC = default( biasC, 33 )
tune = default( tune, "film")
RGmode = default( RGmode, (tune == "film") ? 4 : 1 )
RGmodeC = default( RGmodeC, (tune == "film") ? 4 : 2 )

yy = (RGmode ==0) ? 2 : 3
uv = (RGmodeC==0) ? 2 : 3
LIM1 = (limit>0) ? string( round(limit*100.0/bias-1.0) ) : string( round(100.0/bias) )
LIM2 = (limit<0) ? "1" : string(limit)
BIA = string(bias)
LIM1c = (limitC>0) ? string( round(limitC*100.0/biasC-1.0) ) : string( round(100.0/biasC) )
LIM2c = (limitC<0) ? "1" : string(limitC)
BIAc = string(biasC)

expr = (limit<0) ? "x y - abs "+LIM1+" < x x 1 x y - x y - abs / * - ?"
\ : "x y - abs 0 <= x x "+LIM1+" + y < x "+LIM2+" + x "+LIM1+" - y > x "+LIM2+" - " \
+ "x 100 "+BIA+" - * y "+BIA+" * + 100 / ? ? ?"
exprC = (limit<0) ? "x y - abs "+LIM1c+" < x x 1 x y - x y - abs / * - ?"
\ : "x y - abs 0 <= x x "+LIM1c+" + y < x "+LIM2c+" + x "+LIM1c+" - y > x "+LIM2c+" - " \
+ "x 100 "+BIAc+" - * y "+BIAc+" * + 100 / ? ? ?"

# For (old) MaskTools v1.5.8 :
# yv12lutxy( clp, clp.removegrain(RGmode,RGmodeC), expr,exprC,exprC, Y=yy,U=uv,V=uv)

# For (new) MaskTools v2.x :
mt_lutxy( clp, clp.removegrain(RGmode,RGmodeC), yexpr=expr,uexpr=exprC,vexpr=exprC, Y=yy,U=uv,V=uv)

return( last )
}

[the_weirdo]

Give me exact dlls and script that reproduce the error – I'm building RemoveGrain myself and don't have problems.

Here are some scripts and plugins that can reproduce the error:
https://dl.dropbox.com/u/18695757/Test_Avisynth_2.6_MT.7z

Like Boulder, I also get those plugins from this post:
http://forum.doom9.org/showthread.php?p=1568142#post1568142

After I replace those plugins with their original versions, the error doesn't occur any more. But they're worked fine with previous builds.

[Tempter57]

SEt
Error on SeeSaw.avsi (function sharpen2), GrainFactory3.avs, plugins with original versions

[the_weirdo]

SEt
Error on SeeSaw.avsi (function sharpen2), GrainFactory3.avs, plugins with original versions

With SeeSaw.avsi, you can open it in an editor like Notepad and change float "Spower" to int "Spower" (line #33). That means you cannot use a float value for "Spower" parameter. If you want to keep using float for "Spower" then you need to change int power to float power in function sharpen2 (line #95).

About GrainFactory3.avs, I don't know.

[Tempter57]

the_weirdo
Thank you, with GrainFactory3.avs all good

[forclip]

SEt
Thanks for the build :)


Like Boulder, I also get those plugins from this post:
http://forum.doom9.org/showthread.php?p=1568142#post1568142
These plugins must be recompiled (+small changes) to be compatible with the "new-new" AviSynth 2.6 interface.

-----

Attached DirectShowSource.dll for 2.6.

[SEt]

Plugins in that post (http://forum.doom9.org/showthread.php?p=1568142#post1568142), as forclip said, need to be recompiled for the "new-new" interface. Personally I suggest using classic interface if you don't need something from the "new-new" one.

In SeeSaw.avsi it's clearly the discussed situation of working bugged code due to ints masking as floats. The script should be changed this way:
function sharpen2(clip clp, float strength, float power, float zp, float lodmp, float hidmp, int rgmode)
{
STR = string( strength )
PWR = string( 1.0/power )

[Keiyakusha]

So everything that stopped working I have to modify by hands (in case of script) or get recompiled version (in case of plugin)? Why not just roll back changes that caused this?
Btw this is only MT build, or normal one affected too?

[SEt]

What "everything" is stopped working? I see only plugins built especially for that one build of Avisynth and one previously hidden bug in one script surfaced (what is a good thing).
No idea what "normal one" build you are referencing to.

[Keiyakusha]

Well this is my bad English. Perhaps "anything" suits better there? I have a bunch of scripts that stopped working in new build and that doesn't use any plugins from -Vit-. They return message that invalid arguments was passed, maybe some other messages too. But it works with previous build. I'm not going to investigate which scripts are problematic and where exactly these problems appear.

P.S.
There was build (official?) without MT capabilities. This is what i called "normal"

[SEt]

The int-float change just exposed the hidden problems that you can stumble upon anyway with different parameters for your scripts.
The last "official" build is from 25.05.2011 I think. You are free to use it, but personally I find nothing great there.

[Keiyakusha]

The last "official" build is from 25.05.2011 I think. You are free to use it, but personally I find nothing great there.
I have compiled version from 08.02.12. What I'm actually asking is if this change that "broke" some things is in the trunk or this is your custom upgrade? I said about "normal" version before because some time ago MT stuff wasn't part of the avisynth 2.6, not officially. maybe things changed I don't know. I don't follow actual avisynth development so I'm lost a bit. I don't really need MT stuff anyway. If I still can compile it without MT and this latest change - this is fine. But If everything affected by this change- it really should be rolled back.

[06_taro]

So if anything relying on a buggy behaviour stopped working after a new version fixed it, this bugfix should be rolled back?

[the_weirdo]

So if anything relying on a buggy behaviour stopped working after a new version fixed it, this bugfix should be rolled back?

This actually happen with VSFilter.

How about an additional build until those buggy scripts are fixed?

[SEt]

If you want previous behavior just rollback 1 build back.

[Keiyakusha]

So if anything relying on a buggy behaviour stopped working after a new version fixed it, this bugfix should be rolled back?

Yes. This is one of the cases that can can be called "don't fix what's not broken". I don't recall any problems with that behavior. Until now no one even noticed it! Buggy behavior was there long enough, we can call it feature now.
Edit: What will happen if google will fix buggy behaviour in vp8 bitstream? Or any of the old bugs in vsfilter will be fixed? It will lead to lost compatibility with something but will bring... I don't know what so good it will bring. To me situation with this latest avisynth change looks very similar.
And for example, I have tons of scripts and plugins that I don't even remember where I found and how many times modified. If any of these affected too, I don't see how they will be fixed unless I'll do this myself.

[the_weirdo]

To be honest, I use these builds because they're up-to-date with CVS (which contain some fixes that I may encounter), not because of MT feature. I'm still using a Wolfdale desktop CPU so MT doesn't have much benefit for me. But I don't want to wait for a new official build. I wish there were someone willing to compile "nightly" builds for Avisynth 2.6.

Actually I didn't intend to complain or anything, I just want an additional option for those who cannot wait for those buggy scripts are fixed (I doubt they'll be fixed by their author), like Mosu have done with feature "header compression" of Matroska for MKVtoolnix. I don't use many function scripts and it's trivial for me to fix them (because it's just int-float misplace).

P.S. My English is really poor so if there're offending words or sentences then it's not my intent.

[zerowalker]

QTGMC() doesn´t work for me, something about NNEDI3 Arg 0, this is with the latest build, it work with 1 step earlier.

[manolito]

xp users must extinct. i don't care whether you like it or not. the same happened with win9x users and your whinning won't prevent that!This is a childish statement.

Latest statistics about marketshare of different Windows versions:
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=11&qpcustomb=0

42.52% of all users still use XP. It would be a very bad idea to drop XP support at this time already...



Cheers
manolito

[Overdrive80]

@Set After of updating avisynth with your current version, I got this error:

http://s12.postimage.org/nak51rvfx/Error.png

With version 2012.05.16, it didnt success.

Script used:

SetMemorymax(1024)
SetMtMode(5,4)

DGDecode_mpeg2source("D:\DBZ\DBZ1_12\071\Title_7.d2v", info=3)

ColorMatrix(hints=true, threads=0)

#NO deinterlace

#crop&resize (0,0,-0,-0)
#Opening
D0=Trim(0,2615).Crop(8,0,-6,-4).Spline64Resize(720,480)

#Resumen
D1=trim(2616,4077).Crop(2,0,-2,-0).Spline64Resize(720,480)

#Titulo
D2=trim(4078,4281).Crop(2,0,-2,-0).Spline64Resize(720,480)

#Capitulo - 1 parte
D3=trim(4282,18303).Crop(2,0,-2,-4).Spline64Resize(720,480)

#Cortinillas
D4=trim(18304,18595).Crop(2,0,-2,-0).Spline64Resize(720,480)

#Capitulo - 2 parte
D5=trim(18596,32431).Crop(2,0,-2,-4).Spline64Resize(720,480)

#Ending
D6=trim(32432,34735).Crop(2,0,-2,-0).Spline64Resize(720,480)

#Avance
D7=trim(34736,0).Crop(4,0,-2,-6).Spline64Resize(720,480)

UnalignedSplice(D0,D1,D2,D3,D4,D5,D6,D7)

###################################
# FILTRADO #
###################################

Setmtmode(2)

original=last

aa=spline64Resize(width(original)*2,height(original)*2).SangNom(aa=29).spline64Resize(width(original),height(original)).mergechroma(original)

prefiltrado= dfttest(sigma=4,tbsize=1,tmode=0,lsb=true).ditherpost(mode=2)


super=Msuper(prefiltrado)

backward_vec3 = MAnalyse(super, isb = true, delta = 3, overlap=4,search=4)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4,search=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4,search=4)

forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4,search=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4,search=4)
forward_vec3 = MAnalyse(super, isb = false, delta = 3, overlap=4,search=4)

prefiltrado.MDegrain3(super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,
\thSAD=370,plane=4,lsb=true).ditherpost(mode=2)

contrasharpening(last,aa)

toon(0.10)

gradfun3()

[SEt]

Use the stable 2.5 API (i.e. mt_masktools-25.dll) if you don't want to rebuild the filters but want the latest Avisynth version.

People, these builds are not user-friendly: they are pretty stable and as bug free as possible, but API changes and breaking something old already broken are to be expected. Do not expect that everything will behave as in previous build, especially if you use 2.6 features.

[Keiyakusha]

so by latest api change what exactly we gained other than some broken plugins and scripts?

[Atak_Snajpera]

This is a childish statement.

Latest statistics about marketshare of different Windows versions:
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=11&qpcustomb=0

42.52% of all users still use XP. It would be a very bad idea to drop XP support at this time already...



Cheers
manolito

http://www.w3schools.com/browsers/browsers_os.asp

[the_weirdo]

2) Correct passing of float parameters discussed here (http://forum.doom9.org/showthread.php?t=164974).

Those "buggy" scripts are broken by that change. IIUC, that "fix" isn't commited to CVS Repo yet. And here is IanB's opinion:

[...]
I am not say this should not be fixed, just that it will need banner headlines when we do.

I have had a quick look at doing this fix in ScriptFunction:: and although it is slightly more work it is still trivial and it will have less impact overall.

Like I've said before, I didn't complain at all. I discover that now a float value cannot pass to an int parameter like before, so just find those buggy functions and correct them. FYI, if f is a float, Float(f) is still valid even IsInt(f)=false.

[manolito]

From the w3schools website:
"There are three kinds of lies: lies, damn lies, and statistics."
Benjamin Disraeli
:):)

[Groucho2004]

http://www.w3schools.com/browsers/browsers_os.asp
I don't see how a statistic about the OS behind a browser is representative for the entire market share of an OS.

[active1]

People, these builds are not user-friendly: they are pretty stable and as bug free as possible, but API changes and breaking something old already broken are to be expected. Do not expect that everything will behave as in previous build, especially if you use 2.6 features.

any builds you mean?

[SEt]

Any 2.6 builds.
But if you are using only 2.5 features (not 2.5 bugs) you should be pretty safe.

[pbristow]

Please can we move the silly OS war somewhere else? It's hard enough to track the main discussion without that.

:(

[Stealth5325]

SEt, thank you for all your hard work. I, as well as many others are in your debt.
I was wondering if you'd be so kind as to help me with the basic install of this AviSynth. I'm running Windows 7, with nothing but FFDShow, InterFrame, and AviSynth, and I can't for the life of me use AVISynth with FFDShow without an instant crash.
I'm installing as so:
Downloading the 2.6 ST (x86) from here: http://avisynth.org/mediawiki/Main_Page#Official_builds
Taking your version and putting in c:\windows\syswow64

Then, I run my media player (Win7 media center, properly configured with Win7DSFilterTweaker to enable FFDShow), and run a movie. If AVISynth is checked, instant crash. If not, runs fine. This is with and without a script in the box at all, and with all the options checked/not checked.

I would, of course like to run the 64 bit version, if you have one. I have both 32bit and 64 bit ffdshow installed, from the ffdshow-tryouts website. Most recent official version.
Any suggestions?
Thank you in advance kind sir.

[wOxxOm]

Stealth5325, this might be caused by an incompatible plugin in avisynth\plugins folder, it could be either .dll or .avsi, and if I remember correctly I've used sysinternals' filemon to track which dll/avsi was causing the crash (options->filter = name of avisynth plugins folder). Just run a movie with ffdshow->avisynth enabled, and look in the end of filemon's log.

[Stealth5325]

wOxxOm, thank you for that idea.
I tried to have a look with process monitor, but the folder's not even being accessed.
Even deleting the folder and creating a dummy plugins folder didn't yield results. Any other ideas?

[Stealth5325]

More information:
I've also tried using the SVP project at www.svp-team.org. It works fine with MPC-HC, because it's using the 32 bit FFDShow and 32 bit filters. The minute I install FFDShow x64 and run the SVP manager, it crashes. I'm assuming that manager is running something through AVISynth.
I'm basically feeling like I can't use this 2.6 AVISynth on 64 bit FFDShow. Can anyone help?

[Keiyakusha]

you right you can't have 64bit ffdshow. make sure all your playback chain is 32 bit, you lose nothing anyway.

[Stealth5325]

I've found basically the same thing. 64 bit AVISynth isn't working for me.
I am, however, wanting to use Windows Media Center to run everything, and of course, I use 64 bit Windows, because 4GB RAM doesn't cut it nowadays.
Any way to make 32 bit FFDShow work with 64 bit Windows Media Center?

[Keiyakusha]

Oh I didn't though of WMC. No, you can't make x32 software work with x64...

[forclip]

SEt, can you confirm that your recent build includes this (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/cache.cpp?r1=1.38&r2=1.39&pathrev=MAIN) commit? Because I get this problem (http://forum.doom9.org/showthread.php?p=1581796#post1581796) again.

[SubJunk]

Wish they would start using SVN or Git...

[SEt]

Stealth5325
This build is 32 bit only, so you need 32 bit player. 64 bit builds of Avisynth 2.6 are unlikely.

forclip
Yes it does. Btw, in MT mode it worked this way all the time. If you want to investigate further be sure what mode (MT or not) is activated as they use different caches.

[forclip]

If you want to investigate further be sure what mode (MT or not) is activated as they use different caches.
Thanks, very interesting. When I start my script with SetMTMode >=1 this problem seems to go away. Non-MT cache is broken?!

[lansing]

i have a rare problem here, I can't get the mt running on my machine.

I'm using Windows 7 64bit, and installed everything correctly. A fresh official avisynth with no additional plugins, and then replace the avisynth.dll in the Syswow64 folder with the mt one. And when I called SetMTMode() whatever in the script, it works with no error. However when I tried on different filters, the speed boost I was supposed to get was not there, it just seems like the mt part was not even in the picture. I also tested with filters that were reported to work like trim(), limitedsharpenfaster().

When I ran a script like this on AVSmeter, the line that reports "active MT mode" was 0.
SetMtMode(2)
LimitedSharpenFaster()

[Groucho2004]

When I ran a script like this on AVSmeter, the line that reports "active MT mode" was 0.
SetMtMode(2)
LimitedSharpenFaster()

Post the Avisynth version AVSMeter reports and your complete script.

[lansing]

avsmeter reports:
Avisynth 2.60 build:August 28 2012


MPEG2Source("mt_test.d2v")

SetMtMode(2)
LimitedSharpenFaster()

[IanB]

A SetMtMode statement must be the first line of the script.

[Groucho2004]

I just tried several MT modes with the latest MT version and AVSMeter reports them correctly. No idea why it does not work for you.

Edit: Ouch, it seems that Ian was the first to see the forest for the trees. :o

[lansing]

tried this, but still nothing's change and avsmeter still reports 0. Must be something wrong with my computer but I can't find the problem.

SetMTMode(1,0)

MPEG2Source("mt_test.d2v")

SetMtMode(2)
LimitedSharpenFaster()

[Groucho2004]

Just put "SetMTMode(5)" in the first line.

[lansing]

Just put "SetMTMode(5)" in the first line.

still the same

[Groucho2004]

Sorry, I'm pretty much out of ideas. Probably a long shot - Maybe something in your "autoload" directory is interfering?

[lansing]

Sorry, I'm pretty much out of ideas. Probably a long shot - Maybe something in your "autoload" directory is interfering?

ok i finally got the mt working. After uninstalling Avisynth, I need to delete the entire folder that was left in the program files directory, and that was what got it back working. Previously I tried only empty the plugins folder and that didn't work.


UPDATE:

After further investigation, I was able to find the problematic avs script in the plugins folder, named tbcv01.avs, one i got back in 2008. Removing it will solve the problem. I'll leave a note in the avisynth plugin wiki about this issue.

[fbs]

Which mvtools2.dll should I use with this? I've getting lots of crashes after some hours of processing..

[martin53]

Please allow me to reveal myself as novice. I am using 2.60MTalpha_SEt 8/28/12 and obviously, DeleteFrame(0,0) does not delete two frames, but just one.

Question: is there, and if so where, a bugtracking list, and is this issue maybe already known?

Sorry for causing effort with this probably misplaced post.

[IanB]

DeleteFrame(0,0) is only supposed to delete 1 frame.

The input list is internally sorted, deleting duplicates. The coding choices were to ignore duplicates or throw an error, it was decided by a very small margin that ignoring duplicates would be a more useful implementation.

To delete the first 2 frames either do :-
DeleteFrame(0, 1)
or
DeleteFrame(0).DeleteFrame(0)

[martin53]

Thanks a lot, reasonable.

[mark0077]

Hi, does anyone know how to get around the problem of mpc-hc not closing down properly when using avisynth. I have read on some threads that this is due to a problem somewhere in avisynth / mt? I am using SVP Interframe scripts with the latest avisynth from this thread, and whenever avisynth is enabled in ffdshow, mpc-hc refuses to gracefully shut down about 30% of the time. Sometimes it silently stays there in task manager, other times it will give a program not responding windows dialog.

Any hacked workarounds that has proven to work for anyone or does anyone know the reason for this?

[ney2x]

Hi, does anyone know how to get around the problem of mpc-hc not closing down properly when using avisynth. I have read on some threads that this is due to a problem somewhere in avisynth / mt? I am using SVP Interframe scripts with the latest avisynth from this thread, and whenever avisynth is enabled in ffdshow, mpc-hc refuses to gracefully shut down about 30% of the time. Sometimes it silently stays there in task manager, other times it will give a program not responding windows dialog.

Any hacked workarounds that has proven to work for anyone or does anyone know the reason for this?

What build and revision of ffdshow-avisynth are you using? Have you tried ffdshow builds from xvidvideo.ru or clsid rev4486? I am also experiencing freeze or memory leak of MPC-HC / BE whenever I used xhmikosr ffdshow-avisynth latest builds.

[mark0077]

Hi ney2x, I try to keep upto date with ffdshow builds from xhmikosr's page here http://xhmikosr.1f0.de/ (currently using build 4487)and avisynth 2.6 MT builds from this thread (currently using 2012.08.28: http://www.mediafire.com/file/4dm34k...rk/avisynth.7z). I'll try a different build of ffdshow now from xvidvideo.ru and report back.

EDIT: Wow you're right, I havn't been able to reproduce with the xvidvideo one at least. Opened a video 20 times and got 0 crashes of mpc-hc. Usually I would get at least 6 or 7. I'll ping xhmikosr

[ryrynz]

Yeah I already mentioned this in the ffdshow thread, his ICL12 builds are broken.

[nibus]

Which mvtools2.dll should I use with this? I've getting lots of crashes after some hours of processing..

Me too.. tried a bunch of mvtools2.dll's with no luck, all with different crashes. Reverting back to the last version of MT from this thread to see if that helps.

[bcn_246]

Is there any way to get the MT.dll to work with AviSynth v2.6... or plans to build one... I have tried v0.7 and it (understandably) throws up an error regarding the wrong avisynth.dll version. SetMTMode() gives a speed improvement, but MT("filter") is vastly faster. This is the only reason I still use v2.58.

[SEt]

If you recompile MT.dll it'll probably work the same.

[IJM]

@SEt. Can I offer a suggestion, please? If read ahead buffering is required to make many of these filters (especially temporal ones) work properly in an MT environment, would it not be a good idea to add such a feature into Avisynth 2.6 MT? That way it would be native to the environment, instead of relying on a third party's software being at a reliable patch level? (In fact I'm not keen on being forced to use ffdshow, so I'm running single threaded instead.) Besides, wouldn't it be better to have all the required functionality self contained as part of your Avisynth MT "package"?

For instance, have a SetMTBuffer(framesback int, framesahead int) function. Or build the buffering functionality into existing Avisynth source filters such as avisource() and directshowsource().

I imagine this might not be a trivial piece of work for you, but I thought I'd put it out there as a suggestion to see what you and others think.

[SEt]

I have several interesting ideas but they require quite some time and effort, so no promises when.

[jb_alvarado]

Hello SEt,
I will use your Avisynth.dll in a Batchfile. This Batch check if is avisynth install and when not it will download it via WGet.exe. The Problem is, that WGet can not download from your link. Is it ok for you when I upload your dll to my webspace and share the link?

[SEt]

Avisynth is free software under GPL license, so of course it's allowed.

[Asmodian]

But it is still polite to ask when using someone's build. :)

[bcn_246]

Not really much of a coder or I would re-compile the MT.dll (v0.7) myself. Could anybody modify it to work with AviSynth v2.6 (from what I can see it is just a version check that stops it working - but there may be more).

Regards,

Ben

[Vesdaris]

I suppose there is not much sense in switching to Avisynth 2.6 MT from standard AVS if i don't use on most of my blurays encodes any specific filters, just standard crop\resize?
Would it increase perfomance on interlaced sources?

[bcn_246]

No not really, and quite the opposite if you use any filter other than the ones you mentioned. v2.5.8 with the ability to use MT("*) will be much faster than v2.6 (can only do SetMTMode(*) at the moment, due to the MT.dll not being compatible). The main advantage (IMO) of v2.6 is support for high-depth colour spaces (YV24 etc...) which doesn't really affect Blu-Ray (the spec won't allow higher than 4:2:0, YV12).

[Keiyakusha]

you never thought that mt.dll still not compatible because setmtmode may be better and noone bothered to mess with suboptomal stuff

The main advantage (IMO) of v2.6 is support for high-depth colour spaces (YV24 etc...)
you wanted to say "support for other colorspaces". high bitdepth is not supported.

[bcn_246]

you never thought that mt.dll still not compatible because setmtmode may be better and noone bothered to mess with suboptomal stuff

I wouldn't say MT(* was 'suboptimal' for a lot of filters. Yes, there are filters that processing parts of the image separately is a bad idea for (debanding over large areas, filters that change the number of frames...).

However, provided the user chooses an appropriate orientation and a reasonable amount of overlap, then checks for any visible artefacts were the split parts are joined and adjusts the parameters accordingly) MT(* still provides huge speed benefits with little/no quality loss for a huge number of filters (deblocking, sharpening, de-noising, anti-aliasing...).

Comparing (preview w/VDub, source 1280x720@24 uncompressed YV12 AVI stored on 2xSSDs in RAID-0)
MCTemporalDenoise()
with
SetMTMode(2,8)
MCTemporalDenoise()
with
MT("MCTemporalDenoise(),threads=8,overlap=16,splitvertical=true)
On my i7@4.2GHz the single-threaded version rendered at ~4fps, SetMTMode rendered at ~6fps while MT(... rendered at ~13fps. I couldn't see any visible artefacts (and an overlap of 16 is overkill, for most video an overlap of 4 would have been fine).

Its one small test, but I've used both enough times now to know that splitting the image is considerably faster in every circumstance I have seen and causes issues (when used properly) in very few circumstances.

I haven't had any issues mixing the two with v2.5.8, even when switching multiple times. For example...

SetMTMode(5)
AVISource("blah.avi")
MT("ConvertToYV12",threads=4,overlap=0)
SetMTMode(2,16)
QTGMC(FPSDivisor=2)
SetMTMode(5)
MT("DeBlock_QED(quant1=16,quant2=17)",threads=4,overlap=8)
MT("LSFMod(60)",threads=4,overlap=16)
SetMTMode(2)
GradFun2DBmod(radius=3,str=0)
SetMTMode(5)
Crop(4,6,-2,-8)
Spline36Resize(960,544)
MT("AddGrain(1.2)",threads=4,overlap=0)
MT(* also does work with some filters change the amount of frames. I have used MT("QTGMC",threads=4,overlap=16,splitvertical=true) and have yet to see any 'joins' (or artefacts around the joined area) on the output. It's not like the speed difference between the two is small, in many cases MT(* can be several times as fast as SetMTMode(2).

you wanted to say "support for other colorspaces". high bitdepth is not supported.

Your right, my bad... I was referring to 4:4:4 support...

[SEt]

You are obviously doing something wrong. With 1280x720@24 source running on i7-930@4.1, VDub preview:
DGSource("test.dgi")
MCTemporalDenoise()
4.5 fps

SetMemoryMax(1024)
SetMTMode(3)
DGSource("test.dgi")
SetMTMode(2)
MCTemporalDenoise()

16 fps

[bcn_246]

Just tried again with AviSynth 2.6.0 a3 (110525)...

Got about ~11fps with the same file, which is a big improvement over v2.5.8 RC5 (081230) which gave ~6fps.

Still, not quite as fast as splitting the picture (got ~13fps with MT("MCTemporal... but I can understand were you guys are coming from.

I'll keep playing around, possibly one of the filters it uses is sub-optimal (I have been using Vit-Mod filters were available, and do check for updates pretty often).

Regards,

Ben

P.S.
Set, do you have MultiThreading enabled (in your BIOS) for your over-clocked 930 (so it detects 8 cores)?. I have found it crashes (KERNALBASE error in VDub) with it on...

[SEt]

You need to tweak SetMemoryMax to your case to get the optimal speed and memory consumption. Larger values are not always better though.

Yes, it's fully enabled, so 8 threads. You get crashes in VD likely because its exe isn't LargeAddressAware (google it, it can be easily corrected).

[bcn_246]

...You get crashes in VD likely because its exe isn't LargeAddressAware...

You hit the nail on the head!

I rebuilt the VirtualDub.exe (v1.10.2) PE header to make it LargeAddressAware. Now when running ('preview input'):
SetMemoryMax(1024)
SetMTMode(3,8)
DGSource("720p24test.dgi")
SetMTMode(2)
MCTemporalDenoise()
I am getting 18fps+ on my 1280x720p24 sample.

Thanks for taking the time to help a noob like me (can't even begin to say thanks for everything else you have done here). :D

For others experiencing similar issues here is a ZIP containing LargeAddressAware patched versions of:
VirtualDub v1.9.11 build 32842 (x86)
VirtualDub v1.10.2 build 34807 (x86)
VirtualDubMod v1.5.10.2 build 2542 (x86)

Download Link 1: http://www.mediafire.com/?afapcj020qcra4n
Download Link 2: http://www.sendspace.com/file/borm0d
Virus Scan*: http://virusscan.jotti.org/en-gb/scanresult/8f0031402d6e4603f7b6a5514a1a1b30b8656758

*The files are safe, ClamAV is just complaining about VirtualDubMod being compressed with UPX

[GMJCZP]

Thanks for the input bcn_246.
I have a question: could not do the same with the version of VirtualDubMod 1.5.10.3 build 2550? :thanks:

[bcn_246]

Here ya go:
http://www.mediafire.com/?99z6k97picyo1s8

[djonline]

What about official x64 support ?

[Carpo]

Would be nice if there was official x64 support, the dev's of MeGUI are planning on stopping development of the x64 version as there is no x64 Avisynth support

[SEt]

x64 support for 2.6 is unlikely.

[Poutnik]

Just tried again with AviSynth 2.6.0 a3 (110525)...

Got about ~11fps with the same file, which is a big improvement over v2.5.8 RC5 (081230) which gave ~6fps.

Still, not quite as fast as splitting the picture (got ~13fps with MT("MCTemporal... but I can understand were you guys are coming from.

Is not there a general advice that spatial MT() slicing is a bad idea for MC ?
MT(MCwhatever) speeding up wrt SetMTMode() can be caused by sideeffect of spatial limiting of MC scope, decreasing MC quality.

[Overdrive80]

With last mt avisynth I have troubles to use masktools2. I know that its not trouble of your dll, but could do .dll for avisynth alpha4 with retrocompatibility according to version of date:2012.05.16?

Thanks in advance.

[SEt]

I won't do extra compatibility builds – no one forces you to upgrade, but don't expect any new featured then either.
You want to upgrade – it's time to solve the problems. I'd prefer updated masktools2 to special build of Avisynth.

Expect updated MT version in some days, I'm quite busy atm.

[Overdrive80]

I'd prefer updated masktools2 to special build of Avisynth.


Totally agree with you, but Masktools2 hasnt been updated from 2010; for this reason I request this.

Thanks for your answer.

[SEt]

Masktools2 is open source, so it's not like we can't do minor bugfix for it.

[Overdrive80]

Masktools2 is open source, so it's not like we can't do minor bugfix for it.

All right, I hope someone who knows how to do it can fix these problems. ^^

[tormento]

Set, do you plan to try an alpha4 compile?

[FLauBerT]

"SetMTMode" SeeSaw does not work. XviD is not a problem, but it does not work at x264. Saving work in "Megui has stopped working" error. Every time you go. MT (parameters) as the between 65-80% When using the processor uses the x264 and I'm having a serious waste of time. Processor Intel Corei5 2300. Waiting for your reply. :)

[Selur]

"SetMTMode" SeeSaw does not work. XviD is not a problem, but it does not work at x264.
sounds like you are running out of memory, try to lower the lookahead values in x264

[SubJunk]

Try setting SetMemoryMax to lower. Between 400 and 700 is most stable for me.

[FLauBerT]

Try setting SetMemoryMax to lower. Between 400 and 700 is most stable for me.

Create and save the script in error when I say "stopped working Megui" he says. A problem that occurs only in SeeSaw. SetMTMode scripts (4,4) using the form. A denoise a debanding and using degrain filter. Waiting for your answers.

[Porsche_fan]

I’m having problems running the following script in ffdshow + MPC-HC.

SetMemoryMax(1024)
SetMTMode(3)
ffdshow_source()
SetMTMode(2)
FineSharp(sstr=2.5)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

After a lot of effort, I used subtitle(string(GetMTMode)) to determine GetMTMode(false) returns "0". So I can get the script to work by changing the last line to...

GetMTMode(false) >= 0 ? distributor() : last

The modified script with the mode=0 is a little unstable but that may be related to other variables like SetMemoryMax. Any idea why Mode is "0" despite setting it to "1" in the previous line?

Here are my ffdshow settings

http://thumbnails106.imagebam.com/23802/6f6f45238019517.jpg (http://www.imagebam.com/image/6f6f45238019517)


I recently uninstalled 2.5.8 and replaced it with AVS 2.6.0 Alpha 4 [130114] initially then uninstalled and currently running AVS 2.6.0 Alpha 3 [110525] with 2012.08.28 2.6 MT.

One other question, I've read somewhere else that SEt's avisynth.dll should be placed in the ffdshow folder but I don't think that is correct. Currently there is no avisynth.dll or ffavisynth.dll in my ffdshow folder...is this the correct installation procedure?

Running Windows 7 64 on a i7 860.

[Groucho2004]

I’m having problems running the following script in ffdshow + MPC-HC.

SetMemoryMax(1024)
SetMTMode(3)
ffdshow_source()
SetMTMode(2)
FineSharp(sstr=2.5)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

After a lot of effort, I used subtitle(string(GetMTMode)) to determine GetMTMode(false) returns "0". So I can get the script to work by changing the last line to...

GetMTMode(false) >= 0 ? distributor() : last

The modified script with the mode=0 is a little unstable but that may be related to other variables like SetMemoryMax. Any idea why Mode is "0" despite setting it to "1" in the previous line?

Here are my ffdshow settings

http://thumbnails106.imagebam.com/23802/6f6f45238019517.jpg (http://www.imagebam.com/image/6f6f45238019517)


I recently uninstalled 2.5.8 and replaced it with AVS 2.6.0 Alpha 4 [130114] initially then uninstalled and currently running AVS 2.6.0 Alpha 3 [110525] with 2012.08.28 2.6 MT.

One other question, I've read somewhere else that SEt's avisynth.dll should be placed in the ffdshow folder but I don't think that is correct. Currently there is no avisynth.dll or ffavisynth.dll in my ffdshow folder...is this the correct installation procedure?

Running Windows 7 64 on a i7 860.

1. You're running a single threaded version of Avisynth, that's why GetMTMode() is returning "0".

2. If you're using MPC-HC, you should not be using "Distibutor()" at all, the call is added automatically. So, if you are using Avisynth MT you are unnecessarily increasing the number of threads.

3. "SetMTMode(1)" in your script. Why?

4. The file avisynth.dll (any) should ideally be placed in the Windows or Windows/System32 (sysWOW64 on 64 bit Windows) directory, read the first post in this thread!

[Porsche_fan]

Thanks Groucho2004...I appreciate your reply!

I did read the first post of this thread multiple times and tried to follow it as best as I understood it. I think possibly my last question was misleading. The reason I asked about placing the MT version of avisynth.dll in the ffdshow folder is I read the following from another doom9 member who described one of the steps to setting up 2.6 MT with ffdshow as "- get avisynth 2.6 mt dll and put it in ffdshow directory". As I stated in my first post, I don't think the advice is correct but was asking.


1. You're running a single threaded version of Avisynth, that's why GetMTMode() is returning "0".

4. The file avisynth.dll (any) should ideally be placed in the Windows or Windows/System32 (sysWOW64 on 64 bit Windows) directory, read the first post in this thread!

As mentioned I am able to get multi-threading to work after modifing the script to GetMTMode(false) >= 0 ? distributor() : last. So based on this I believe I am running a MT version of avisynth.

However, I realize that mode=0 indicates the state of no multi-threading so possibly what you said has some truth. From the instructions I did the following...installed AVS 2.6.0 Alpha 3 [110525] (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) then moved the avisynth.dll file from 2012.08.28 (http://www.mediafire.com/file/4dm34kc7tug7rrk/avisynth.7z) into syswow64 replacing existing avisynth.dll from the initial installation. If I did this incorrectly what should I have done?


2. If you're using MPC-HC, you should not be using "Distibutor()" at all, the call is added automatically. So, if you are using Avisynth MT you are unnecessarily increasing the number of threads.

3. "SetMTMode(1)" in your script. Why?

I have tried it without the distributor() call but couldn't get multi-threading to work with ffdshow in MPC-HC until it was added.

The reason I use the SetMTMode(1) and distributor() is because SEt said it was necessary on the first post of this thread and also in this post (http://forum.doom9.org/showthread.php?p=1351603).

Appreciate the help!

[Groucho2004]

From the instructions I did the following...installed AVS 2.6.0 Alpha 3 [110525] (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) then moved the avisynth.dll file from 2012.08.28 (http://www.mediafire.com/file/4dm34kc7tug7rrk/avisynth.7z) into syswow64 replacing existing avisynth.dll from the initial installation. If I did this incorrectly what should I have done?
That sounds right to me.

The reason I use the SetMTMode(1) and distributor() is because SEt said it was necessary on the first post of this thread and also in this post (http://forum.doom9.org/showthread.php?p=1351603).
In that case ignore points 2. and 3. from my previous post. I have little experience with ffdshow so maybe someone else may be more helpful.

Either way, if GetMTMode() from your script returns "0", you are not using the correct (MT) Avisynth DLL. Make sure there is only one avisynth.dll on your system (in your syswow64 directory).

Edit: Do you really need Avisynth MT for FineSharp? As far as I know, it's quite fast.

[Porsche_fan]

Do you really need Avisynth MT for FineSharp? As far as I know, it's quite fast.

I agree I find my experience using singled threaded FineShap puzzling as you are right it is pretty fast. I always resize everything prior to applying FineSharp so that is an added factor.

DVD playback while using avisynth spline64 resizing before FineSharp has been trouble free. However, I have had differening results using FineSharp single threading with x.264 720/1080p with some instances of audio and video desynching. Desyncing seems to usually occur with x.264 encoded 720p @30fps...so far 24fps hasn't been an issue.

In some cases I've been able to solve the desync problem by having ffdshow decode but I prefer using the MPC AVC codec. I know ffdshow is suppose to be less CPU intensive when decoding but I can't think it should make that big a difference given the i7 processor.

I also had a strange issue with AVC in an avi container that had sync issues but it was fixed when I put it in a mkv container. Anyways, I've found that 2.6 MT allows the overhead/flexibility to use any codec without desync.

The really odd part to me is the graph pattern with or without multi-threading is the same in resource monitor for my i7 860 @2.8Ghz. In both cases 4 cores are parked and the other 4 cores that are active distribute the load equally and are at about 40% utilization. It could be that I have an issue with the way my computer is set up to process information. Would be interested in others thoughts.

EDIT: Don't know if this is the same for everyone else but after I uninstalled 2.5.8 I deleted the remaining folder labeled "AviSynth 2.5". I then installed 2.6 Alpha 3 but the new AviSynth 2.6 program is in a folder in Program Files (86) still labeled "AviSynth 2.5" not "AviSynth 2.6". I did use Version() to verify it is the 2.6 Alpha 3 build.

[LigH]

Some extremely annoying semi-freeware converters (ERightSoft SUPER, FormatFactory) are able to bend the hook to an own copy of an AviSynth DLL. But I believe the repeated re-installation of AviSynth versions should have repaired it, if that was a possible reason; still, better scan all your harddisk partitions for any copy.

[ryrynz]

Do not use SetMTMode(3). Use SetMTMode(3,4)!
mt_lutxy, mt_lut, FFmpegSource use a lot of memory. 8 threads will eat your memory faster.

Also 8 threads on i7 is useless. You will get slow execution, because most time the processor
will switch threads and wait for spin locks.

I use GraphstudioNext to benchmark my scripts (Psharpen, Awarpsharp, Vaguedenoiser etc) and on my 2600K with Hyperthreading I get a considerable performance improvement having 8 threads over 4.
My recommendation would be to test this for yourself.

[CraziFuzzy]

How close are you to rolling out an MT version of 2.6 Beta-4?

[LigH]

Last asked in #607 (http://forum.doom9.org/showthread.php?p=1612236#post1612236); no reply from SEt yet.

[SEt]

It took longer than I expected, but here we go – updated version. Can't say I've tested everything, so let's keep 'stable' status on previous one for some time.

rean, please don't write nonsense. i7-930 with 8 threads is my work environment for the last 3 years and so you can say "native mode" of these builds. Also, if you are doing things right, FFmpegSource will consume exactly the same amount of memory regardless of number of threads used.

[LigH]

... but here we go – updated version.

http://cosgan.de/images/smilie/froehlich/e035.gif (http://www.cosgan.de/smilie.php)

I will immediately get you a bunch of german-speaking testers!

[ryrynz]

Latest build is stable for me, cheers SEt.

[SEt]

rean, that you personally have problems is valid statement. But On i7 you will always get crashes. Do not use SetMTMode(3). Use SetMTMode(3,4)! is nonsense.

[forclip]

Do we need to recompile something again or is it a bug:


Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 198139200


And so on (with different digits at the end). But only with this build, not with the build by IanB (14.01.2013).

I know I must provide more info, but it's quite hard to do as I'm not an expert in all those plugins, just noticed that in my application all (or mostly all) filtering presets is broken with this build. Deinterlacing with QTGMC() for example:

Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 129064256
(D:\Program Files\Winnydows\XviD4PSP5\dlls\AviSynth\plugins\QTGMC.avs, line 776)
(D:\Program Files\Winnydows\XviD4PSP5\dlls\AviSynth\plugins\QTGMC.avs, line 386)

line 776:
diff = mt_makediff( Ref, Input, U=3,V=3 )

line 386
repair0 = (IsClip(srchClip) || Rep0 == 0) ? binomial0 : binomial0.QTGMC_KeepOnlyBobShimmerFixes( bobbed, Rep0, (RepChroma && ChromaMotion) )

[LigH]

QTGMC is certainly a useful monster of testing script... :D

Are these already "fatal" error messages, or may it be useful to have DebugView running while testing?

[forclip]

Seems like false alarm :)

mt_masktools-26.dll 2.0.48.0 944Kb (966 656 bytes) - was the problem. It is something old that claims to be compatible with AviSynth 2.6, but in reality it uses AvisynthPluginInit2. Works fine after replacing it with another build that uses AvisynthPluginInit3 and avisynth.h somewhere from the summer of 2012 (i.e. after the "new-new" interface was introduced).

But another part of my question is still valid: do we need to recompile everything again using recent avisynth.h or not? I see that avisynth.h in DirectShowSource isn't updated, so may I guess that all this new caching features currently not used in existing plugins and it is not neccessary to recompile them?

[invy]

! C:\Users\v\AppData\Local\Temp\avisynth_20130220.7z: Unknown method in avisynth.dll
! C:\Users\v\AppData\Local\Temp\avisynth_20130220.7z: Error - operation failed


Winrar message ^^

[LigH]

Your 7-zip DLL used in WinRAR may be outdated (the file is compressed with LZMA2, available since v9.04); use a current 7-zip:

http://www.7-zip.org
http://sourceforge.net/projects/sevenzip

[invy]

Yeah I googled it pretty easily right after posting. Problem solved after updating to latest version.

Just a heads up to anyone dumb/lazy like me that still was using a Winrar version from 2007! (3.71) :)

[forclip]

Do you mean mt masktool is not compatible with this Avisynth build?
I'm talking only about mt_masktools-26.dll. And yes, it isn't compatible with current AviSynth MT, but not with the latest official non-MT (aka Alpha4). I don't know why. The code can be simplified to something like this:


LoadPlugin("......\mt_masktools-26.dll")

ColorBars(pixel_type="YV12")
mt_average(last)

=

Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 136600896

[Overdrive80]

Just checked - yes. I got this error, too. Previous stable version works.

Its issue known, its necessary that should be fixed in mt_masktools_26.dll.

http://forum.doom9.org/showthread.php?p=1589904#post1589904

http://forum.doom9.org/showthread.php?p=1589960#post1589960

http://forum.doom9.org/showthread.php?p=1610927#post1610927

[SEt]

forclip, I get exactly the same error from official Alpha4. Actually, without MTMode my build should behave exactly like official. MTMode changes several things, so there can be problems (but here turning on MTMode actually makes it work with no error).

About recompiling: I suggest using 2.5 interfaces (unless you need something 2.6-specific) – this way you don't need to recompile each time. But if you are using 2.6 interfaces – be ready to recompile as official interfaces are changing.

[blindbox]

The download links are down. Mediafire should no longer be used, apparently. Anyone has a mirror?

[SEt]

I never thought Mediafire became this bad. Written them all I think about their quality, but don't expect any improvements. I'm open for suggestions of stable public (not personal) hosting (in PM).

Uploaded the archive as attachments to first post.

Well, I can say attachment rules here are also awful: not only attachments require approval, but also extremely limited in variants. Why the archive must be <= 200k? Oh and useless zips are somehow at premium and allowed 300k. More than that: it refuses 'multivolume' 7z in form name.7z.001 . These limits make absolutely no sense as all they do is prevent me from using the most compact format.

[tormento]

SEt: dropbox or skydrive? You can make a public link.

[LigH]

Here is a little backup (http://forum.gleitz.info/showthread.php?46165-AviSynth-2-60a4-MT-von-SEt&p=435017&viewfull=1#post435017) of mine; just repacked with optimal compression.

[SEt]

Updated first post to Dropbox links. Report if you have any problems with it.

[IanB]

@rean,

Every thread that interacts with COM must initialise COM, you have rogue threads using the COM environment.

Try COINIT_APARTMENTTHREADED, it adds an protection apartment that may get you around the problem.

[SEt]

First of all you are using MTMode wrong: the lineGetMTMode(false)>0 ? Distributor() : lastis special hack for FFDShow and must not be used when you use Avisynth the regular way by opening avs script.

If you'd still get crashes without that line, my initial guess is that Ut Video codec does something wrong as I see no crashes with FFV1 also. Try to test with different codecs.

[SEt]

New build – updated to cvs.

[06_taro]

A minor updated build of mt_masktools-26.dll for 2.60alpha4's latest interface (current cvs 2013-03-09):
mt_masktools-26-for-2.6alpha4.7z (http://tmod.nmm-hd.org/Misc/mt_masktools-26-for-2.6alpha4.7z)

Patch (on top of Vit (http://forum.doom9.org/showthread.php?p=1568142#post1568142)'s 2.6 fixed one) included.

[forclip]

New build – updated to cvs.
Thanks!

[Overdrive80]

A minor updated build of mt_masktools-26.dll for 2.60alpha4's latest interface (current cvs 2013-03-09):
mt_masktools-26-for-2.6alpha4.7z (http://tmod.nmm-hd.org/Misc/mt_masktools-26-for-2.6alpha4.7z)

Patch (on top of Vit (http://forum.doom9.org/showthread.php?p=1568142#post1568142)'s 2.6 fixed one) included.

Thanks very much

[radigast]

A minor updated build of mt_masktools-26.dll for 2.60alpha4's latest interface (current cvs 2013-03-09):
mt_masktools-26-for-2.6alpha4.7z (http://tmod.nmm-hd.org/Misc/mt_masktools-26-for-2.6alpha4.7z)

Patch (on top of Vit (http://forum.doom9.org/showthread.php?p=1568142#post1568142)'s 2.6 fixed one) included.Was this build specifically made for QTGMC compatibility? I still get access violations when opening an .avs script that calls QTGMC (v. 3.33) using this modded mt_masktools with AviSynth 2.6.0 Alpha 4 and SEt's most recent avisynth MT (013.03.09). Reverting to avisynth MT (2012.05.16) fixes the problem.

[06_taro]

What is your QTGMC setting?
With default settings it works for me with both official alpha4 and SEt's latest MT version:
http://s21.postimage.org/zba6a3t1x/possibility.png (http://postimage.org/image/qt0q5rmj7/)

Also note that although the plugin was built by VS2012 with v110_xp profile, the huge boost libraries were built soon after my initial installation of VS2012 without update1 and I didn't recompile them with the new profile, so I cannot guarantee its capability on Win XP.

Edit: I managed to catch the access violations by using other Vit's old 2.6 fixed plugins. I was using 2.5 version of them except for masktools2, so I only updated it and didn't notice the same issue with other plugins. Then I recompiled some of them with the new interface and now they worked again. However, I don't think it makes sense to do so, because AFAIK none of those dependencies supports 2.6's new colorspace except for masktools2 and AddGrainC, and fortunately the latest version of the latter (1.7.0) does not need to be recompiled. So I prefer to keep using 2.5 version of the rest plugins instead of risking myself for unrevealed bugs during conversion to the new interface.

[LigH]

3 - one filter instance per call in script, Avisynth guards requests for output. The mode to use with source filters. (Mode 5 will do for them too, but is overkill and should be avoided.)

Okay, sounds reasonable together with the warning on the AviSynth MT support page (http://avisynth.org/mediawiki/MT_support_page):

Mode 5 is the slowest (slower than not using SetMTMode) but should work with all filters that don't require linear frameserving (that is the frames come in order: frame 0,1,2,...,last).

:o

Now there is this rumour that DGSource() in DGDecNV may require Mode 5.

Any comments to explain this opinion?

There are MT modes explained (http://avisynth.org/mediawiki/MT_modes_explained) in detail only up to Mode 2.
__

P.S.:

DGSource appears to work in Mode 3 without crashing; at least in a trivial script. May there be risks with more complex scripts with broader temporal windows?

Furthermore, AviSynth 2.60a4 appears to use a lot less memory in MT mode than in non-MT mode.

See: Post in the german doom9/Gleitz board (http://forum.gleitz.info/showthread.php?45902&p=435516#post435516)

[radigast]

What is your QTGMC setting?SetMemoryMax(1500)
SetMTMode(3,6)
LoadPlugin("C:\Program Files (x86)\Encoding Tools\Video\MeGUI\tools\avs\directshowsource.dll")
DirectShowSource("E:\...Source.mkv", fps=25.000, audio=false, convertfps=false)
crop(240, 0, -240, 0)
Spline64Resize(960,1080) # Spline64 (Sharp)
SetMTMode(2)
QTGMC(Preset="Slower",FPSDivisor=2,EdiThreads=6)
SetMTMode(3)
Spline64Resize(960,720) # Spline64 (Sharp)

I managed to catch the access violations by using other Vit's old 2.6 fixed pluginsThat was the problem. I was using Vit's 2.6 plugins. As the avisynth from 2012.05.16 runs QTGMC stable with Vit's 2.6 plugins and the above script, I'm not too worried about using the newest avisynth and reverting to Vit's 2.5 plugins. Thanks for the response and problem identification, though.

Edit: And, yeah, DirectShowSource sucks, but I can't be arsed to index the files...

[Selur]

but I can't be arsed to index the files...
You could try LWLibavVideoSource, which uses libav and allows to use it without indexing (if you set cache = false)

[zerowalker]

I get the error:

nnedi3: arg 0 must be a clip!
(QTGMC-3.32.avsi, line 721)
(QTGMC-3.32.avsi, line 510)

When i use Avisynth 2.6 later then 2012.05.16 i think.

Tried searching on it, but i can´t find anyone else who got it, atleast not in english.

[bennynihon]

Using SEt's latest Avisynth 2.6 MT and Masktools 2.0a48, I'm having an issue with frames being processed out of order when I enable MT via SetMTMode. In my output video (encoded by x264), I'll occasionally see a few interchanged frames which is noticeable as jumpiness in the output clip. When I comment out the SetMTMode lines, the issue disappears. I have tried mt_masktools-25.dll, mt_masktools-26.dll (both 2.0a48 and the for2.6alpha4 build) with Avisynth 2.6 MT, and mt_masktools-25-x64.dll and mt_masktools-26-x64.dll with SEt's 64-bit Avisynth as well. I've pretty much tried all permutations with MT enabled and the restults are the same. Occasional (a few every minute) frames being processed out of order. Not sure if this is an interaction between FFmpegSource2 and Masktools in Multithreaded mode. It also appears limited to the MAnalyse, motion compensation type filters with forward and backward motion vectors.

My clip is something as simple as this:

# Video Source
SetMemoryMax(1024)
SetMTMode(3)
FFVideoSource("e:\mymovie.mkv")

SetMTMode(2)
# Crop to 1920x800 (2.40:1 AR)
vSrc=Crop(0,140,0,-140)

# Degrain
bs = 16
super = vSrc.MSuper(pel=2, sharp=1)
bvec2 = MAnalyse(super, isb = true, delta = 2, blksize=bs, overlap=bs/2)
bvec1 = MAnalyse(super, isb = true, delta = 1, blksize=bs, overlap=bs/2)
fvec1 = MAnalyse(super, isb = false, delta = 1, blksize=bs, overlap=bs/2)
fvec2 = MAnalyse(super, isb = false, delta = 2, blksize=bs, overlap=bs/2)
vSrc.MDegrain2(super,bvec1,fvec1,bvec2,fvec2)

[06_taro]

Your script has nothing to do with masktools2, what it uses is mvtools2.

[bennynihon]

Your script has nothing to do with masktools2, what it uses is mvtools2.

You're absolutely right! That's embarrassing. My full script includes a lot of Masktools calls, which is why I had it engrained in my mind. But in trying to debug the source of the problem I had completely removed all Masktools calls, leaving just the MVTools lines. No wonder why the different Masktools variants didn't help my cause! I'll have to dig deeper with MVTools.

UPDATE: Updating to FFMS2 r742 did the trick!

[LigH]

I am still curious (http://forum.doom9.org/showthread.php?p=1619659#post1619659) about a deeper explanation of the MT modes >3.

[LigH]

Is SEt the only person who can explain the MT modes in detail?

[Evil_Burrito]

Is SEt the only person who can explain the MT modes in detail?

Probably one of the few. I think mode has to do with read/write cycles. The longer a filter waits in the memory, the more memory needed/used, thus slowing down the process. But honestly, I don't know.

[bxyhxyh]

Can SetMTMode(1) load all internal filters?

[LigH]

It won't be recommendable for any *Source filters, even internal (e.g. AviSource / OpenDMLSource), because there may be some "non-reentrant" VfW codecs (which will get confused and return corrupt video when executed more than once; this can already be provoked by having more than one video source call in one script). I remember such a failure for a VfW codec originally shipped with Windows XP, I believe it was either MS Video 1 or Cinepak.

Issues with MT source calls might also be circumvented by the function RequestLinear which is provided by TIVTC; example: RequestLinear(rlim=50,clim=50) — this hint (http://forum.gleitz.info/showthread.php?46230-Avisynth-MT-nicht-immer-sinnig&p=435815&viewfull=1#post435815) by courtesy of Didée

Apart from that, most filters should be parallelizable; I can't think of academical exceptions right now, but I can't exclude their existence a priori.

[chevy]

seem to be running into a problem.i installed official 2.6 replaced the avisynth.dll in sys32 and WOW folder ,when i go to preview my script i get this error
http://img703.imageshack.us/img703/6002/2993d00c38d48523362bcae.png
any help would be great.i've been messing for days trying to figure out MT and get it working.

[LigH]

If you have a 32-bit Windows, replace the 32-bit AviSynth DLL in C:\Windows\system32.

If you have a 64-bit Windows, replace the 32-bit AviSynth DLL in C:\Windows\SysWOW64. Do not replace any 64-bit AviSynth DLL in C:\Windows\system32. There is no MT replacement for AviSynth 64-bit. Use only a 32-bit AviSynth MT. If you have a 64-bit encoder, use a pipe bridge (e.g. avs4x264mod.exe) to forward the output of a 32-bit AviSynth MT to the 64-bit encoder, to avoid it trying to use the 64-bit AviSynth which is unstable and lacks of 64-bit plugins. Better remove the 64-bit AviSynth installation completely, it is not recommendable until it gets reliable.

[chevy]

thanks for the quick response.i removed it from the SysWOW64 folder now i am getting the error there is no function named "MT" when i try and preview my script.

[LigH]

Exactly wrong for a 64-bit Windows.

The 32-bit AviSynth DLL is in SysWOW64. This one you should have kept.

The 64-bit AviSynth DLL is in system32. This one you should remove. And ensure that only the remaining 32-bit AviSynth installation is used, by both 32-bit and 64-bit encoders.

[chevy]

ok so i re installed the newest avisynth 2.6.i removed the avisynth.dll from the sys32 folder i tried my script and got the same erro about no function named "MT".So then i replaced the SysWOW64 avisynth.dll with the modified avisynth.dll on the first page of this thread.still same error

[LigH]

Then scan through all harddisk partitions everywhere for other copies of avisynth.dll, you probably have a mess of too many old versions; if AviSynth couldn't be found at all, the error would be different (like not being able to handle *.avs files).

Maybe you are using MeGUI (which provides an own copy of AviSynth in case it is not correctly installed)? You are providing too few useful details; we can not even be certain that you are not trying to use a 64-bit AviSynth...

[chevy]

yes im useing megui.i installed a 32bit version of avisynth 2.6.so should i delete all avisynth.dll's i find except the one in C:\Windows\SysWOW64?

i just manually loaded the modified avisynth.dll and went to preview my script and it froze megui(turned all the screens white)

[StainlessS]

Uninstall ALL versions of Avisynth, search for all copies of Avisynth.dll and delete, and new reinstall again.
If you mean System32, then say System32 and not sys32. Also, re-read everything that LigH said.

EDIT: It may be suffiicient to rename your MeGUI directory (temporarily) instead of deleting the dll from there.

[chevy]

ok i will do all that now,again thank you both for the replys. :)

[Groucho2004]

got the same erro about no function named "MT".
It looks like you're trying to use the MT plugin with Set's DLL. It's not supported any more.
Also, post your script!

[chevy]

Ok so how dose one install and use MT now?.I'm just trying it with this
mt("spline36resize(720,last.height)")
mt("spline36resize(last.width,400)",splitvertical=true)

[Groucho2004]

Ok so how dose one install and use MT now?
One doesn't. Read the first post in this thread, it explains how to use the multi-threading functions.

[Evil_Burrito]

Ok so how dose [sic] one install and use MT now?.I'm just trying it with this
mt("spline36resize(720,last.height)")
mt("spline36resize(last.width,400)",splitvertical=true)

Distributed frames are preferred over sliced frames these days. Look at the example "Differences between MT() and SetMTMode()" on http://avisynth.org/mediawiki/MT_support_page.

With a little research/reading you can answer your own questions without even asking :-)

[chevy]

Ok so i deleted all avisynth.dll's.I installed the newest avisynth 2.6 32bit.i replaced the avisynth.dll in C:\Windows\SysWOW64 with the modified one from the first post and still getting same error there is no function named "MT".

[Groucho2004]

Ok so i deleted all avisynth.dll's.I installed the newest avisynth 2.6 32bit.i replaced the avisynth.dll in C:\Windows\SysWOW64 with the modified one from the first post and still getting same error there is no function named "MT".
If you don't post the script (as I asked you to), nobody will be able to help.

[chevy]

i did post it earlier but here it is again,sorry i see i didn't post it all earlier here it is now

LoadPlugin("C:\Users\root\Desktop\MeGUI_D\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\Users\root\Documents\VIDEO_TS\VTS_02_1.d2v", info=3)
LoadPlugin("C:\Users\root\Desktop\MeGUI_D\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
crop(0, 2, 0, 0)
#resize
#denoise
mt("spline36resize(720,last.height)")
mt("spline36resize(last.width,400)",splitvertical=true)

[Groucho2004]

i did post it earlier but here it is again,sorry i see i didn't post it all earlier here it is now

LoadPlugin("C:\Users\root\Desktop\MeGUI_D\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\Users\root\Documents\VIDEO_TS\VTS_02_1.d2v", info=3)
LoadPlugin("C:\Users\root\Desktop\MeGUI_D\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
crop(0, 2, 0, 0)
#resize
#denoise
mt("spline36resize(720,last.height)")
mt("spline36resize(last.width,400)",splitvertical=true)
I see you didn't read the instructions in the first post of this thread.
You're still wrapping your resize calls with "mt", a function from a plugin that is not supported by this version of Avisynth.
Also, I don't know why you are even trying to multi-thread such a simple script which would be more than fast enough running in a single thread.

[chevy]

i was just useing that for testing ,So drop the MT i assume and use SetMTMode()

[Groucho2004]

So drop the MT i assume and use SetMTMode()
Correct.

[luke83]

I'm using that Avisynth MT version: http://code.google.com/p/avisynth-mt/
It works good for me. Why should i use yours?

[Q-the-STORM]

I'm using that Avisynth MT version: http://code.google.com/p/avisynth-mt/
It works good for me. Why should i use yours?

well.. if you read what's there on the site of your link, then you'll know that:
This is SEt's 2.5.8 MT version compiled with MSVC 2010 (SP1) so it will run on Windows XP SP3 and newer.
it's also SEt's dll, only the old 2.5.8

And if you read the first post, you'll know that in the version from this thread
MT mode stability is way better than Avisynth 2.5.8, general stability - the same as official Avisynth 2.6 (which is again better than 2.5.8 due to many bugfixes since then).

[luke83]

i use both SetMTMode and MT. I use MT only with FluxSmoothT (temporal smoother) couse it doesn't work with setmtmode.

here is my script. I've deleted some settings


SetMTMode(1,0)
<Plugin loading and/or importing>
MPEG2_Source()
Colormatrix()
SetMTMode(2,0)
# Deinterlacer
AssumeTFF().Telecide(guide=1).Decimate(mode=1,threshold=2.0)
# Spatial Denoiser
RemoveGrain(2).RemoveGrain(2)
# Temporal Denoiser
MT("FluxSmoothT(temporal_threshold=7)",2)
# Cropper
crop()
# Resizer
Spline16Resize()
# Dehalo
fft3dfilter(bt=-1, plane=0, dehalo=1.0, hr=2.0, ht=50, svr=0)
# Sharpener
MSharpen(threshold=10, strength=100,mask=false, highq=true)
aWarpSharp()
ToonLite(0.2)
# Anti-aliasing
AAA()


How can i use any temporal smoother with your new version if i can't use MT("") anymore? :)

Thanks in advance

EDIT:
fluxsmooth produces several artifacts and i've discovered that i've never used it really until now, couse setmtmode makes it unuseful if you don't use MT("") function
Today, when I've used MT(""), it worked but not as good as expected, so i've removed it.

Then i've installed your avisynth version in system32 folder. Have I to replace avisynth.dll file in megui folder too? (I've portable version of megui)

[LigH]

MeGUI preferably uses the installed AviSynth version. An own copy was added in case the user did not install any other AviSynth. This may happen for a "portable" use where installing AviSynth was not possible (e.g. due to a missing administrative access).

I am surprised that FluxSmoothT is an example for a filter which fails with the current multithreading process, and I am certainly interested in details why. Apart from that ... you are using a lot of filters, I really wonder if a different and smaller selection can produce a similar result with less efforts. Especially the double sharpen makes me wonder which kind of source requires that. Or which kind of audience?

[luke83]

MeGUI preferably uses the installed AviSynth version. An own copy was added in case the user did not install any other AviSynth. This may happen for a "portable" use where installing AviSynth was not possible (e.g. due to a missing administrative access).

I am surprised that FluxSmoothT is an example for a filter which fails with the current multithreading process, and I am certainly interested in details why. Apart from that ... you are using a lot of filters, I really wonder if a different and smaller selection can produce a similar result with less efforts. Especially the double sharpen makes me wonder which kind of source requires that. Or which kind of audience?
k. I've replaced megui version too.

About the double sharpener.
MSharpener is the real sharpener.
aWarpsharp is the filter i use to have lighter lines.
ToonLite is to make darkener lines. aWarpsharp sometimes make it too light
AAA is for anti-aliasing
I'm encoding Lupin 2nd Season

EDIT:
the problem was this version of avisynth. It made a green band on bottom of the video and a lot of artifacts during playing. I've replaced with 2.5.8 version (always Set build) and now it works again

[GMJCZP]

Using AnimeIVTC has submitted the following error message:

Avisynth Open Failure:
Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 25161872
And says there is a problem with SRestore, AnimeIVTC, in that order. In the script is not enabled SetMTMode.

I am using the Avisynth 2.6.0 MT version of the March 9, 2013

[LigH]

You will have to use a patched version of MaskTools2 (http://forum.doom9.org/showthread.php?p=1619023#post1619023).

[GMJCZP]

It worked! Thank you.

[aldix]

Been having problems w/ setmtmode since upgrading to the latest version.

I have 2.5.8 official installed & replaced with latest 2.6 MT in SysWOW, I'm on x64 system (win7).

Script is as follows:

[quote]
setmtmode(5)
setmemorymax(768)
MPEG2Source("C:\Users\redacted\VTS_06_1.d2v", cpu=0)
Crop(16, 0, -12, -0)
Spline36resize(688, 560)
Load_Stdcall_Plugin("c:\program files (x86)\avisynth 2.5\plugins\yadif.dll")
ConvertToYV12(interlaced = true)
global deinterlaced_part = Yadif(order=1)#.Subtitle("deinterlaced frame", align=5)
ScriptClip(last, "IsCombedTIVTC(last, cthresh=7, MI=40) ? deinterlaced_part : last")

import("c:\program files (x86)\avisynth 2.5\plugins\ChubbyRain3.avs")
import("c:\program files (x86)\avisynth 2.5\plugins\vinverse.avs")

Chubbyrain3(thr=5,str=10) ## before anyone notes, this shouldn't be the culprit as x264 hangs both w/and w/o

import("c:\program files (x86)\avisynth 2.5\plugins\ylevels.avs")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\ContraSharpen.avs")
import("c:\program files (x86)\avisynth 2.5\plugins\sbr.avs")
import("c:\program files (x86)\avisynth 2.5\plugins\HQDering.avs")
import("c:\program files (x86)\avisynth 2.5\plugins\BlindDehalo3_mt2.avs")
import("c:\program files (x86)\avisynth 2.5\plugins\DetailSharpen.avs")
loadplugin("c:\program files (x86)\avisynth 2.5\plugins\RedAverage.dll")
loadplugin("c:\program files (x86)\avisynth 2.5\plugins\asharp.dll")
loadplugin("c:\program files (x86)\avisynth 2.5\plugins\flash3kyuu_deband.dll")
import("c:\program files (x86)\avisynth 2.5\plugins\Minblur.avs")

#ColorYUV(gain_y=0,cont_y=0,cont_u=0,cont_v=0,gain_v=0,gain_u=-0,off_y=0,off_u=-0,off_v=-0)

blksize = 16
overlap = blksize/2
hpad = blksize/2
vpad = blksize/2
lambda = 512
search = 5

setmtmode(2)

source = last
preNR = source.bicubicresize(source.width*2, source.height*2).blur(1.3).SharpenDetail(str=2, thr=2).bicubicresize(source.width, source.height)
preNR_super = preNR.MSuper(hpad=hpad, vpad=vpad, pel=2, sharp=2, rfilter=2)
source_super = source.MSuper(hpad=hpad, vpad=vpad, pel=2, sharp=2, levels=1)
vb2 = MAnalyse(preNR_super, isb=true, truemotion=false, delta=2, blksize=blksize, overlap=overlap, search=search, lambda=lambda)
vb1 = MAnalyse(preNR_super, isb=true, truemotion=false, delta=1, blksize=blksize, overlap=overlap, search=search, lambda=lambda)
vf1 = MAnalyse(preNR_super,isb=false, truemotion=false, delta=1, blksize=blksize, overlap=overlap, search=search, lambda=lambda)
vf2 = MAnalyse(preNR_super,isb=false, truemotion=false, delta=2, blksize=blksize, overlap=overlap, search=search, lambda=lambda)

# Use the vectors to create motion and static masks, we use these for prefilter and sharpening masks
maskstar = source.mt_binarize(upper=false)
maskmotion1 = mt_average(source.mmask(kind=0, vb2, gamma=1, ml=130),source.mmask(kind=0, vb1, gamma=1, ml=130))
maskmotion1 = mt_adddiff(maskmotion1, mt_makediff(maskmotion1,source))
maskmotion2 = source.mt_motion(thy1=5,thy2=10,thc1=5,thc2=10,u=3,v=3).mt_lut(expr="x 255 == x 156 - 0 ?")
maskmotion = mt_lutxy(maskmotion1,maskmotion2,expr="x 0 == 0 x y < y x ? ?")
maskstatic = mt_invert(maskmotion)

NR = source.MDegrain2(source_super,vb1,vf1,vb2,vf2,thSAD=300,thSCD1=400,thSCD2=102,limit=102,plane=4)
den = mt_merge(NR,source,maskstar)

ContraSharpen(den,source)
# DEBANDING
f3kdb(sample_mode=2,dynamic_grain=false,keep_tv_range=false,dither_algo=3,y=48,cb=24,cr=24,grainY=48,grainC=24)
BlindDehalo3(rx=2.5, ry=2.5, strength=125)
HQDering()
tweak(sat=1.3, coring=true)
YlevelsS(10,1.0,250,0,255,false)
trim(0, 9000)
#interleave(source.trim(0,9000), last)
[quote]

If I attempt to encode the above (using Mulder's Simple x264 GUI), 2-pass encode hangs in the beginning of 2nd pass, whereas
crf hangs soon after initiating (just tried with adding Distributor() in the end of the script and it hanged under 2k frames, though cpu load was 100% all the time).
Msg is something along the lines of "x264 didn't respond for 60 seconds, it may be deadlocked".

Conversely, when I run the same script w/o any MT involvement at all, it encodes more or less on the same speed (2nd pass/crf @ ~2-2.4 fps on my 4-core i5) and
does it successfully until the last frame w/o hanging.

And it isn't the only script currently which I'm having trouble with. It's just one example which, even so, is cut to basics (it was initially a lot longer and until now worked perfectly fine).

So... what gives?

Thanks a lot in advance!

edit: And when it doesn't hang, I get this (tried with yet another script/source):

x264 [error]: 2nd pass has more frames than 1st pass (8000 vs 442)
x264 [error]: x264_encoder_open failed

edit#2: Additionally, if I'd add this snip of code in the end of the script while there are no SetMTMode and/or SetMemoryMax calls employed,

# display mode and number of threads in use
#Subtitle("Number of threads used: " + String(GetMTMode(true))
# \ + " Current MT Mode: " + String(GetMTMode()))

I get the result that threads used=4 (max of my cpu) and mode (obviously) 0. But how come can there be all the threads in the works if I
haven't explicitly called them?! (And cpu load when encoding is also 100% then, shouldn't it be lower given that MTing isn't indicated within the script?)

I apologize for such a long post, but I'm really, really stumped on this. Help!

[real.finder]

aldix

try use MP_Pipeline (http://forum.doom9.org/showthread.php?t=163281)

you have two choices, the 1st one is split the script in MP_Pipeline

and the 2nd is increase setmemorymax in MP_Pipeline

the using of MP_Pipeline (even without split) make the avs process independent of x264, and that will make both of them work comfortably

More details http://forum.doom9.org/showthread.php?p=1628332#post1628332

edit: And when it doesn't hang, I get this (tried with yet another script/source):

x264 [error]: 2nd pass has more frames than 1st pass (8000 vs 442)
x264 [error]: x264_encoder_open failed

I have no idea, but it seems that wrong from you because x264 says that the number of frames is different from the first pass

edit#2: Additionally, if I'd add this snip of code in the end of the script while there are no SetMTMode and/or SetMemoryMax calls employed,

# display mode and number of threads in use
#Subtitle("Number of threads used: " + String(GetMTMode(true))
# \ + " Current MT Mode: " + String(GetMTMode()))

I get the result that threads used=4 (max of my cpu) and mode (obviously) 0. But how come can there be all the threads in the works if I
haven't explicitly called them?! (And cpu load when encoding is also 100% then, shouldn't it be lower given that MTing isn't indicated within the script?)

I apologize for such a long post, but I'm really, really stumped on this. Help!

I have no idea, but the x264 is using all threads By default

[LigH]

IIRC, MTMode uses the detected number of cores as default if the very first SetMTMode() call does not limit it, therefore GetMTMode(true) will probably return the detected number of cores, no matter if multithreading is enabled at all. If GetMTMode(false) returns 0, then no multithreading was enabled, only one thread is used.

Regarding the different frame counts: It looks like the statistics from a different first pass still existed. Maybe from a compressibility test. Be certain that a full 1st-pass encoding finished right before the matching 2nd-pass starts.

[aldix]

I appreciate the replies, thanks!

MP_Pipeline certainly sounds intriguing. Though is it of any use with 4GB RAM?

For my primary problem, I ended up doing some manual grunt work of attempting the encode with only parts of the script (manalyse+degrain only, then +masks, then the rest of the filters one at a time).
Consequently I discovered that HQDering appears to pull down MT functionality (1st pass is never at 100% - fluctuating between 50% and ~85% - while 2nd is but eventually crashes). Once I commented it out, everything normalized.

I moved on to doing some tests with hqdmod (by Mf) & HQDeringMod v0.4 (by mawen1250) and while both seem to require a preceding SetMTMode() to take 100% out of CPU, 1st pass runs at 100% w/o dropping
and 2nd pass doesn't hang with a "potential deadlock". My humble n00b thoughts are that perhaps all these problems are due to patched Masktools (due to latest 2.6 MT version), but then later mods shouldn't work normally either, so I
don't know...

No idea what's the frame count stuff was all about, either.

Thanks again for all the feedback. I'll definitely check out MP_Pipeline, much obliged, real.finder!

[pbristow]

MP_Pipeline certainly sounds intriguing. Though is it of any use with 4GB RAM?


I've used it successfully with only 3GB (though I have 4GB now, which helps a lot! :) )

You just have to be careful not to use too many threads, and/or to use SetMemoryMax() appropriately (and bear in mind that the SetMemoryMax() function doesn't set the *total* memory used by the script, or the thread instance; it just sets the amount of *frame cache*. The plugins you use will also use some memory of their own; How much depends on how complex they are. A useful rule of thumb, then, is to take the total memory you want to let avisynth use (NB this *MUST* be no more than half your physical memory), divide that by the number of threads you intend to run (to get the maximum memory use per thread), and then divide that by two (allowing each thread to use half its memory space for frame cache). If you have problems, or things seem to be really slow, try running your script against a short clip with two or three different settings of SetMemoryMax, to see whether increasing or decreasing it is likely to help.

The second way of going about it is to estimate how much frame cache you script actually *needs* to run efficiently... but that requires a fair bit of knowledge about how the filters you're using work and interact with each other. Also, it might scare you into spending money on more RAM. ;)

Then there's the third way, which is what I've settled on myself: Just start by bunging SetMemoryMax(64) at the start of each script (including each "mini script" within the MP_Pipeline() call), and then try dropping it to 48 later if there's a chance it might help. :) 64MB per thread usually works fine with four or five threads, and it's enough cache space to store 20 full-HD frames in YV12 format, which is plenty for most scripts.

[aldix]

Everything sounds good, but somehow it doesn't successfully load for me, tried with both read-me example (loadplugin("MP_Pipeline.dll") and explicitly (loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\MP_Pipeline_0.14\x64\MP_Pipeline.dll"). In first case it just doesn't find it (well, duh!) and in the latter, gives the error=0xc1 unable to load.

Trying it with this, basically mimics read-me examples and Your suggestion, pbristow (appreciated!):


loadplugin("MP_Pipeline.dll")
MP_Pipeline("""
SetMemoryMax(64)
f3kdb(sample_mode=2,dynamic_grain=false,keep_tv_range=false,dither_algo=3,y=48,cb=24,cr=24,grainY=48,grainC=24)
BlindDehalo3(rx=2.5, ry=2.5, strength=125)
hqdmod()
### prefetch: 5,2
### branch: 3
### ###
""")


Would love to actually employ it. What am I doing wrong?

edit: No loadplugin error if I'd use x86 version, but now I'm getting errors with all the filters involved ("unable to create slave process ... script error: invalid arguments in function ...").
Huh?

[LigH]

This question is probably more related to MP_Pipeline than to AviSynth-MT.

[real.finder]

Everything sounds good, but somehow it doesn't successfully load for me, tried with both read-me example (loadplugin("MP_Pipeline.dll") and explicitly (loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\MP_Pipeline_0.14\x64\MP_Pipeline.dll"). In first case it just doesn't find it (well, duh!) and in the latter, gives the error=0xc1 unable to load.

Trying it with this, basically mimics read-me examples and Your suggestion, pbristow (appreciated!):


loadplugin("MP_Pipeline.dll")
MP_Pipeline("""
SetMemoryMax(64)
f3kdb(sample_mode=2,dynamic_grain=false,keep_tv_range=false,dither_algo=3,y=48,cb=24,cr=24,grainY=48,grainC=24)
BlindDehalo3(rx=2.5, ry=2.5, strength=125)
hqdmod()
### prefetch: 5,2
### branch: 3
### ###
""")


Would love to actually employ it. What am I doing wrong?

edit: No loadplugin error if I'd use x86 version, but now I'm getting errors with all the filters involved ("unable to create slave process ... script error: invalid arguments in function ...").
Huh?

the x64 is for avs 64, SEt build is 32 so you have to use x86

and you must put all files that attached in x86 folder in MP_Pipeline Package to avs plugins folder

and try to read MP_Pipeline_readme.avs for the correct using

This question is probably more related to MP_Pipeline than to AviSynth-MT.

you right

[aldix]

the x64 is for avs 64, SEt build is 32 so you have to use x86

and you must put all files that attached in x86 folder in MP_Pipeline Package to avs plugins folder

and try to read MP_Pipeline_readme.avs for the correct using



you right


Yeah, you're all right, I apologize. Going to post my questions to the relevant thread shortly.

[LigH]

I am still curious (http://forum.doom9.org/showthread.php?p=1619659#post1619659) about a deeper explanation of the MT modes >3.

Especially now that a user in the german doom9/Gleitz board reported (http://forum.gleitz.info/showthread.php?46373-Fehler-in-der-Framereihenfolge-durch-MT) issues with MPEG2Source rarely producing stray frames with MTMode 3. Is MTMode 5 here still necessary? We would understand better if we understood their differences in detail.

[Groucho2004]

Especially now that a user in the german doom9/Gleitz board reported (http://forum.gleitz.info/showthread.php?46373-Fehler-in-der-Framereihenfolge-durch-MT) issues with MPEG2Source rarely producing stray frames with MTMode 3. Is MTMode 5 here still necessary? We would understand better if we understood their differences in detail.
Have a look at IanB's posts, like this (http://forum.doom9.org/showthread.php?p=1627093#post1627093) and this (http://forum.doom9.org/showthread.php?p=1629239&highlight=changefps#post1629239). Might be helpful.

[LigH]

OK, thank you very much. This is indeed what I was looking for.

A function Preroll() was mentioned which was introduced in AviSynth MT 2.60 alpha 4; I believe a quite similar feature is offered by TIVTC with RequestLinear() (http://forum.doom9.org/showthread.php?p=804225#post804225).

[IanB]

As I said in the other thread modes 3, 5 and 6 are identical for source filters.

They all implement the same single mutex lock on the GetFrame call. As source filters by definition do not have a child, the different child behaviour of modes 3, 5 and 6 is irrelevant.

[IanB]

I am still curious (http://forum.doom9.org/showthread.php?p=1619659#post1619659) about a deeper explanation of the MT modes >3.

A quick review of the AvisynthMT modes (a revised entry) :-

Mode 1: Unprotected access to a single instance of the filter. All the threads may enter the GetFrame routine concurrently. Code has to be fully thread safe and re-entrant.

Mode 2: Unprotected multiplexed access to thread count instances of the filter. The thread will enter the GetFrame routine of the next free instance of the filter. Code only has to be instance safe. Each filter instance only sees a non-contiguous proportion of the GetFrame calls.

Mode 3: Protected access to a single instance of the filter. Only 1 thread may be within the GetFrame routine concurrently, the lock is released while the routine executes it's child->GetFrame() calls and waits for and reacquires the lock when the child call completes. Code has to be instance safe, re-entrant, and the code up to the child->GetFrame() call thread safe. The filter instance sees all of the GetFrame calls.

Mode 4: Protected multiplexed access to thread count instances of the filter. Only 1 thread may enter the GetFrame routine of the next free instance of the filter, the lock is released while the routine executes it's child->GetFrame() calls, allowing another thread to enter a different instance of the filter. It waits for and reacquires the single lock when the child call completes. Code can be mostly slack, statics and globals must still be thread safe or read only. Like mode 2 each filter instance only sees a non-contiguous proportion of the GetFrame calls, but unlike mode 2 only 1 instance is allowed to run at a time. The code up to the child->GetFrame() call does not need to be thread safe.

Mode 5 and 6: Protected access to a single instance of the filter. Only 1 thread may be executing the GetFrame routine. When the routine executes a child->GetFrame() call the lock is NOT released. However a mini-distributor pre-fetches a number of frames from the remaining graph. The pre-fetch thread count is based on the number, N, of threads concurrently waiting for any mode 5 filter lock. Mode 5 runs N pre-fetch threads, mode 6 runs N+1 pre-fetch threads. Code can be fully slack, statics and globals do not need to be thread safe.

Filters that need to see all accessed frames for their processing algorithm should avoid modes 2 and 4.

Most filters upon entry immediately execute a child->GetFrame(n ,env) call. This prologue is usually re-entrant and thread safe. When this is not so filters need to use mode 2, 4, 5 or 6.

This immediate child->GetFrame behaviour tends to restrict the efficacy of the mode 5 mini-distributor. The active thread grabs the lock, charges straight through to the child->GetFrame routine and finds there are no mode 5 gate waiting threads YET, so start no pre-fetch threads. Other threads arriving and then waiting happens during the long processing phase of the filter. As the first thread completes and releases the lock, the next next thread similarly grabs the lock, charges straight through to the child->GetFrame routine and probably finds there are still no mode 5 gate waiting threads. The first thread is off dealing with the result it calculated, the now running thread is no longer a mode 5 gate waiting thread.

With many concurrent threads and a single heavy lifting mode 5 filter that does bottleneck a reasonable number of threads at once the mode 5 mini-distributor pre-fetching can become effective. Resorting to mode 6 may result in more concurrent ready threads than available cores to run them which can cause cross core L1/L2 cache spoiling, this might be mitigated by selecting 1 fewer initial threads than cores on the first SetMTMode call.

Including source filters as mode 5 is a contentious issue. The wait time is usually fairly short and all the threads usually end up hitting the source so can increase the global mode 5 gate waiting thread count by the average source waiting thread count, which like mode 6 may result in more concurrent ready threads than available cores to run them.

Careful design of the script and much testing is required to achieve optimal performance with AvisynthMT. There is no one size fits all. Never measure CPU business as a criterion (all the cores might be spinning their wheels calculating the same frame multiple times), always check the final FPS.

[pbristow]

[DELETES ENTIRE ENTRY]

Ignore me, I somehow missed the fact there'd been plenty of replies to that question already. :)

[pila13]

Hello guys, i need small help with MT, actualy, more like "consultation"

I use this plugin with dfttest, mode 2, but, after chat with fwe people hwo use it back in 2012, i recive not very positive feed backs. Main notice "MT, cause out put of bad frames" i already burned about 10 rips, since yasterday, and didn'tn otice any problem, but it's take about 1,5 - 2 h on burning, since iwhtout Mt - 3.7 - 4.1 fps, but with MT 6.25, or even more.

any how, can any one showme how this "bad frame" look like ? Thank You !

[LigH]

It will probably depend more on the source plugin, less on the filter plugins. There are video decoders which may not like being called by many concurrent threads, requesting often changing positions from the source video. If they are not programmed "thread-safe" (a.k.a. "reentrant"; it mainly means consequently avoiding global variables, to allow each thread having its own independent set), then it may happen that they partially return content to one thread which another thread requested, like luma and chroma from different frames.

Allegedly, MPEG2Source (DGMPGDec) confused the chrominance of averagedly one frame per 3..5 minutes in this german report (http://forum.gleitz.info/showthread.php?46355&p=437176#post437176) even though it ran in MT mode 3. Hard to prove or disprove this assumption if it doesn't happen on your PC... We are still discussing this case, but the concerned user is not the most rational-thinking. ;)

[Groucho2004]

Hello guys, i need small help with MT, actualy, more like "consultation"

I use this plugin with dfttest, mode 2, but, after chat with fwe people hwo use it back in 2012, i recive not very positive feed backs. Main notice "MT, cause out put of bad frames" i already burned about 10 rips, since yasterday, and didn'tn otice any problem, but it's take about 1,5 - 2 h on burning, since iwhtout Mt - 3.7 - 4.1 fps, but with MT 6.25, or even more.

any how, can any one showme how this "bad frame" look like ? Thank You !
1. There is no need to use dfttest with Avisynth MT, the plugin already features multi-threading
2. I guess the people who told you about the "bad frames" know best what they look like
3. Use a spell checker next time you post

[pila13]

thank you for replyas.

>> LigH
humm, i recive + 2 fps when use MT, before dfttest. I see, but i don't use mt, on a source.

SetMTmode(3,0)
MPEG2Source(".d2v")

only before filters. And i didn't had this problem.

[Genaugmen]

I get errors when trying to extract the file. I have downloaded at least 7-8 times. I've tried extracting with winrar and 7zip. Winar says "avisynth_20130309.7z: Unknown method in avisynth.dll". 7zip says "unsupported compression method for 'avisynth.dll". I can't find a mirror either. Help, please! I should also mention that I have tried all of this with antivirus disabled too, so that's not the issue. I also have the same problem with the previous version. I didn't have an issue with the version prior to that, but it's hosted somewhere else.

[Groucho2004]

I get errors when trying to extract the file. I have downloaded at least 7-8 times. I've tried extracting with winrar and 7zip. Winar says "avisynth_20130309.7z: Unknown method in avisynth.dll". 7zip says "unsupported compression method for 'avisynth.dll". I can't find a mirror either. Help, please! I should also mention that I have tried all of this with antivirus disabled too, so that's not the issue. I also have the same problem with the previous version. I didn't have an issue with the version prior to that, but it's hosted somewhere else.
Works just fine with 7z v9.2 and Winrar v4.

[Genaugmen]

I've been using the same old versions for years. Just tried with the newest version of 7zip and it extracted fine. Thanks!

[LigH]

Version 9.2x introduced the better multi-threaded LZMA2 algorithm.

[cihub]

No matter what scripts I use (mainly with MCTDmod and QTGMC) at some point in time AviSynth tends to stop working. Usually it happens like this: counter of processed frames in x264 (or VirtualDub) stops increasing, but CPU is still used (~30% on my AMD FX-6300), even if I cancel processing (Ctrl+Break with x264 or program closing with VirtualDub).

The scripts I've used mainly look like this:
#plugins
SetMTMode(3)
#source: Mpeg2Source("d2v.d2v")
SetMTMode(2)
#filters: QTGMC(Preset="fast"); SelectEven(); MCTD()
Distributor()
SetMTMode(3)
#post-processing: resize, crop
or
#plugins
SetMTMode(3, 6)
#source: Mpeg2Source("d2v.d2v")
SetMTMode(2)
#filters: QTGMC(Preset="fast", EdiThreads=3); SelectEven(); MCTD()
Distributor()
SetMTMode(3)
#post-processing: resize, crop

Any ideas what's causing crashes?

[Groucho2004]

Any ideas what's causing crashes?
- QTGMC and/or MCTD are probably not getting enough memory. Try playing with "SetMemoryMax()".
- Get rid of "Distributor()". x264 calls that function.
- Use fewer threads.

[Selur]

also there shouldn't be and additional setmtmode calls behind distributor(),...

[cihub]

Groucho2004, Selur thank you. Will try that tomorrow.

BTW, 1) when I do not use Distributor(), at least in AvsP, CPU usage stays at the level of AviSynth 2.5.8, i.e. like there's no MT 2) SetMemoryMax() set to 768--2000 MB had no result at all (well, maybe there was something different like the time it took to crash, but it still crashed).

[Groucho2004]

BTW, 1) when I do not use Distributor(), at least in AvsP, CPU usage stays at the level of AviSynth 2.5.8, i.e. like there's no MT 2)
Don't know about Avsp. If you use x264, omit the Distributor call in the script.

SetMemoryMax() set to 768--2000 MB had no result at all (well, maybe there was something different like the time it took to crash, but it still crashed).
Add the functions one by one (first QTGMC, then MCTD). Also, test the script without the encoder first, use AVSMeter (http://forum.doom9.org/showthread.php?t=165528) to check the speed, CPU and memory usage.

[Jeroi]

Could you add DXVA support also? AInt GFX cards good at video prosessing?

[LigH]

DXVA support in the AviSynth kernel? I doubt that there would be any gain. The video processing features of DXVA will be too specifically related to small parts in video decoding and won't be useful for general purpose.

[junh1024]

You may be able to use DXVA in avs already by using dss or dss2, and an appropriate directshow filter.

[kalehrl]

My script crashes if there is colormatrix entry in it when using Avisynth 2.6 MT.
This is the offending entry:
LoadPlugin("D:\Programs\MeGUI_0.3.5_x86_WithoutInstaller_OfflinePackage\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
When I remove it, the script opens just fine.
Does anyone know if there is a different version of colormatrix plugin that work with MT?
My existing colormatrix is 2.5.

[kalehrl]

Unfortunately, it is the same with the file you suggested.
This is the script I use:
SetMTMode(3, 4)
LoadPlugin("D:\Programs\MeGUI_0.3.5_x86_WithoutInstaller_OfflinePackage\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Dreambox\movie\projectx\VTS_02_1[copy].d2v", info=3)
LoadPlugin("D:\Programs\MeGUI_0.3.5_x86_WithoutInstaller_OfflinePackage\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
SetMTMode(2)
AssumeBFF()
QTGMC(Preset="Super Fast")
SelectEven()
Spline36Resize(720,406) # Spline36 (Neutral)
MeGUI won't even load the script unless I remove colormatrix entry.

[Boulder]

Try to put SetMTMode(5) right before ColorMatrix.

[Groucho2004]

Unfortunately, it is the same with the file you suggested.
This is the script I use:
SetMTMode(3, 4)
LoadPlugin("D:\Programs\MeGUI_0.3.5_x86_WithoutInstaller_OfflinePackage\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Dreambox\movie\projectx\VTS_02_1[copy].d2v", info=3)
LoadPlugin("D:\Programs\MeGUI_0.3.5_x86_WithoutInstaller_OfflinePackage\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
SetMTMode(2)
AssumeBFF()
QTGMC(Preset="Super Fast")
SelectEven()
Spline36Resize(720,406) # Spline36 (Neutral)
MeGUI won't even load the script unless I remove colormatrix entry.
With a SD source and super fast preset for QTGMC, I wonder why you need Avisynth MT at all. What CPU do you have?

[kalehrl]

I've got an old DualCore AMD Athlon II X2 240, 2800 MHz (14 x 200) processor and 4 GB of RAM.
With a default QTGMC setting, I've got only 5 FPS but with super fast around 11.5 FPS.
Without avisynth MT I've got only 3 FPS with a default QTGMC setting.
Even with super fast QTGMC gives better results than YADIF.
Try to put SetMTMode(5) right before ColorMatrix.
Excellent!
It works by just putting SetMTMode(5) before ColorMatrix.
Thank you Boulder.

[Groucho2004]

I've got an old DualCore AMD Athlon II X2 240, 2800 MHz (14 x 200) processor and 4 GB of RAM.
With a default QTGMC setting, I've got only 5 FPS but with super fast around 11.5 FPS.
Without avisynth MT I've got only 3 FPS with a default QTGMC setting.
Even with super fast QTGMC gives better results than YADIF.
OK. As already suggested, try SetMTMode(5) instead of 3. Also, specifying more threads than you have cores makes little sense.
So, your script should look like this:
SetMTMode(5)
LoadPlugin("D:\Programs\MeGUI_0.3.5_x86_WithoutInstaller_OfflinePackage\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Dreambox\movie\projectx\VTS_02_1[copy].d2v", info=3)
LoadPlugin("D:\Programs\MeGUI_0.3.5_x86_WithoutInstaller_OfflinePackage\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true)
AssumeBFF()
SetMTMode(2)
QTGMC(Preset="Super Fast")
SelectEven()
Spline36Resize(720,406)

[Boulder]

Excellent!
It works by just putting SetMTMode(5) before ColorMatrix.
Thank you Boulder.Good to know that it helped. I don't know why but there are some filters that do not like mode 3 even though it should be basically a single-thread setting. TDecimate is one those who need SetMTMode(5) to work properly.

[kalehrl]

So, your script should look like this:
Thanks. For simplicity's sake, I'll just stick with SetMTMode(5) at the beginning of the script instead of SetMTMode(3) at the beginning and then again SetMTMode(5) before colormatrix.
Regarding threads, I read that they should be number of cores times 2 for hyperthreading.
I tested the script with SetMTMode(5, 4) and again with SetMTMode(5) and there's very little difference in speed.

[Groucho2004]

Thanks. For simplicity's sake, I'll just stick with SetMTMode(5) at the beginning of the script instead of SetMTMode(3) at the beginning and then again SetMTMode(5) before colormatrix.
Why? Once you set a mode, the processing will remain in that mode until you change it. It's the opposite of simplicity (although won't do any harm).

Regarding threads, I read that they should be number of cores times 2 for hyperthreading.
Your AMD does not support hyperthreading.

[LigH]

@ Boulder:

Despite the fact that SEt claimed all modes from 3 up are now exactly the same in AviSynth MT 2.60 a4 ... obviously still not exactly?

[CarlPig]

Any plan for MT update to 2.6.0 Alpha 5?

[Groucho2004]

Any plan for MT update to 2.6.0 Alpha 5?
That may take a while, SEt hasn't posted here in months.

[CarlPig]

Ok...

[bcn_246]

Haven't had any problems running SEt's 2013-03-09 MT build (avisynth_20130309.7z (https://www.dropbox.com/s/xhqggxamegia420/avisynth_20130309.7z)) with v2.6 Alpha 5 here. Will test it some more.

[LigH]

You misunderstood: SEt's AviSynth MT 2.60 a4 replaces AviSynth 2.60 a5.

[Overdrive80]

Haven't had any problems running SEt's 2013-03-09 MT build (avisynth_20130309.7z (https://www.dropbox.com/s/xhqggxamegia420/avisynth_20130309.7z)) with v2.6 Alpha 5 here. Will test it some more.

If you do that, really working with the alpha version 4.

[bcn_246]

Okay...

Using...
1. AviSynth_130918.exe (CRC32: 973AC633)
2. Which includes the following version of avisynth.dll (CRC32: 7C8B3879)
3. Replaced with SEt's MultiThreaded version of avisynth.dll (CRC32: 4E3DD2EE)

Gave no problems opening...
AVISource("1080pSample.avi")
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
SetMemoryMax(2048)
SetMTMode(2,8)
DeBlock_QED()
Crop(4,2,-4,-2)
Spline36Resize(1280,720)
GradFun2DBmod(str=0)

[IanB]

@bcn_246,

And your point is? :confused:

SEt's 2013-03-09 MT build is derived from Alpha4, Jan 14th, 2013. If you install Alpha5 and replace it with SEt's Alpha4 avisynth.dll, you are running SEt's Alpha4.


And the SetMemoryMax(2048) is a ridiculous value. As I keep telling people setting the size of the Avisynth frame cache bigger than what the current script needs is a waste.

[LigH]

The core of AviSynth is only this DLL.

[tormento]

As I keep telling people setting the size of the Avisynth frame cache bigger than what the current script needs is a waste.

How should we determine the correct amount?

[Groucho2004]

How should we determine the correct amount?
It's impossible to calculate the correct value because of the complexity of filter combinations like QTGMC.
So, you have to experiment. Start with something like 1500 and reduce it until your script slows down (or crashes). Then go back to the previous value.
I successfully used Avisynth MT/SetMemoryMax(1024) with QTGMC (slow preset) on HD material.

Don't just test it with a few frames, let it run for a few minutes. AVSMeter is a good tool for these experiments.

[ryrynz]

How should we determine the correct amount?

I've had blocky corruption of frames with SetMemoryMax(1000) I've set back to 1500 and everything seems fine now.

[Seedmanc]

I remember some script eating way too much memory and eventually crashing when I used this command, while working nicely without it. Don't know details though.

[LigH]

There may be more updated files between alpha 4 and alpha 5. But the most important file (the "kernel" which represents AviSynth, and defines the version) is only the one DLL.

Other included files are just a few plugins, example scripts, and the documentation. Nothing which really depends on the minor version or would even define it.

[SEt]

Updated to Alpha5.


Despite the fact that SEt claimed all modes from 3 up are now exactly the same in AviSynth MT 2.60 a4 ... obviously still not exactly?
I never claimed such thing... Only that mode 3 and mode 5 for source filters are the same.

[Boulder]

Thanks a lot!

[LigH]

Updated to Alpha5.

:thanks:

I never claimed such thing... Only that mode 3 and mode 5 for source filters are the same.

Well – it is hard to understand, and it stays hard to understand.

There are indeed cases when modes 3..6 do behave differently (e.g. NeatVideo VDF).
__

And there may also be cases when AviSynth MT just can't handle a filter (or vice versa) with more than 1 thread: At least we (in the german board) are currently trying to get DeSpot in an MT sequence running without crashing; the most stable mode in a report of a user appears to be mode 4, but it is always unreliable, sometimes the crash is earlier, sometimes later. There seems to be a discouraging statement about DeSpot in another location.

[Sparktank]

Updated to Alpha5.

:goodpost::thanks:

[PetitDragon]

[QUOTE=SEt;1645637]Updated to Alpha5.

This is just greate!:thanks:

[CarlPig]

A minor updated build of mt_masktools-26.dll for 2.60alpha4's latest interface (current cvs 2013-03-09):
mt_masktools-26-for-2.6alpha4.7z (http://tmod.nmm-hd.org/Misc/mt_masktools-26-for-2.6alpha4.7z)

Patch (on top of Vit (http://forum.doom9.org/showthread.php?p=1568142#post1568142)'s 2.6 fixed one) included.

Please update to 2.60alpha5 MT.

[LigH]

Does AviSynth MT 2.60 alpha 5 introduce a new interface again, so that MaskTools2 have to be adapted again? I didn't hear about any crashes since, yet. So I believe there was only this one change between versions up to alpha 3 and from alpha 4 on?

[Groucho2004]

So I believe there was only this one change between versions up to alpha 3 and from alpha 4 on?
Correct. There are no API changes that would require plugin updates from A4->A5.

[CarlPig]

I dont know, but the answers says that i need a patch.

I got this problem: http://forum.doom9.org/showpost.php?p=1647078&postcount=200

I use 2.60alpha5 MT and the lastest masktools build.

[Groucho2004]

I use ... the lastest masktools build.
This (http://forum.doom9.org/showthread.php?p=1619023) one?

[CarlPig]

Yes..

[Groucho2004]

Yes..
Works for me. Check if you have some old DLLs in the auto-load directory.

[06_taro]

http://www.nmm-hd.org/upload/get~ytQx5-3uVdE/alpha5mt.jpg

Works for me.
How can I re-produce it?

[CarlPig]

I have found out it works for some files and not for other files.

It does not work with this:
General
Unique ID : 175099253835760043288826361198420018304 (0x83BAE3BE268212C4A92F46E85D5DC480)
Complete name : R:\Test1.mkv
Format : Matroska
Format version : Version 2
File size : 2.29 GiB
Duration : 1h 47mn
Overall bit rate : 3 052 Kbps
Encoded date : UTC 2012-07-02 06:16:20
Writing application : mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 3 2010 22:54:08
Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 47mn
Bit rate : 3 000 Kbps
Width : 1 024 pixels
Height : 720 pixels
Display aspect ratio : 1.422
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.170
Stream size : 2.19 GiB (96%)
Writing library : x264 core 115 r1995kMod c1e60b9
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x13 / me=umh / subme=7 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=2 / sliced_threads=1 / slices=2 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc=abr / mbtree=0 / bitrate=3000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Muxing mode : Header stripping
Codec ID : A_AC3
Duration : 1h 47mn
Bit rate mode : Constant
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Channel positions : Front: C
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 49.1 MiB (2%)
Language : Danish
Default : Yes
Forced : No

But it works with this:
General
Unique ID : 181167790535246177777077846563243667618 (0x884BA5B3D0FF8AF93D7534787643B0A2)
Complete name : R:\Test2.mkv
Format : Matroska
Format version : Version 2
File size : 1.66 GiB
Duration : 29mn 3s
Overall bit rate : 8 201 Kbps
Encoded date : UTC 2013-07-20 22:07:44
Writing application : MakeMKV v1.8.4 win(x64-release)
Writing library : libmakemkv v1.8.4 (1.2.0/1.1.0) win(x64-release)

Video
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : No
Format settings, Matrix : Custom
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 29mn 3s
Bit rate : 7 846 Kbps
Maximum bit rate : 8 000 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.757
Time code of first frame : 00:02:00:00
Time code source : Group of pictures header
Stream size : 1.59 GiB (96%)
Language : English
Default : No
Forced : No
Color primaries : BT.601 PAL
Transfer characteristics : BT.470 System B, BT.470 System G
Matrix coefficients : BT.601

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 29mn 3s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 39.9 MiB (2%)
Title : 2/0
Language : Danish
Default : Yes
Forced : No

Text
ID : 3
Format : VobSub
Codec ID : S_VOBSUB
Codec ID/Info : The same subtitle format used on DVDs
Language : Danish
Default : Yes
Forced : No

Menu
00:00:00.000 : en:Chapter 01
00:10:28.320 : en:Chapter 02
00:19:00.960 : en:Chapter 03

[CarlPig]

http://www.nmm-hd.org/upload/get~ytQx5-3uVdE/alpha5mt.jpg

Works for me.
How can I re-produce it?

I have try with this simple command: LSFmod()

It works with Test2 but not with Test1.

[06_taro]

Tried:Version().ConvertToYV12
BilinearResize(1024, 720)
AssumeFPS(24000, 1001).Loop(10000)
AudioDub(BlankClip(audio_rate=48000))

LSFmod()
Info
But still couldn't catch any error. Don't know any clip properties that would cause such a cache problem. Could you please make sure that there's exactly only one mt_masktools-*.dll in you computer and try again?

[Groucho2004]

I have try with this simple command: LSFmod()

It works with Test2 but not with Test1.
If it works for one source and not the other, I suspect you don't have the correct decoder.

Posting your script might be useful. :rolleyes:

[CarlPig]

Here:
SetMemoryMax(512)
SetMTMode(3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
DGSource("D:\Test1.dgi",fieldop=0)
SetMTMode(2)
Spline64Resize(768,576) # Spline64 (Sharp)
LSFmod()
And
SetMemoryMax(512)
SetMTMode(3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
DGSource("D:\Test2.dgi",fieldop=0, deinterlace=1)
SetMTMode(2)
crop(24, 2, -10, -6)
Spline64Resize(768,576) # Spline64 (Sharp)
LSFmod()

[CarlPig]

Tried:Version().ConvertToYV12
BilinearResize(1024, 720)
AssumeFPS(24000, 1001).Loop(10000)
AudioDub(BlankClip(audio_rate=48000))

LSFmod()
Info
But still couldn't catch any error. Don't know any clip properties that would cause such a cache problem. Could you please make sure that there's exactly only one mt_masktools-*.dll in you computer and try again?

You have right, there was a old mt build in my dir.

Sorry for all post due a old build.

[martin53]

My apologies if I report something that is already known:

With V2.60, I observe some black stripes with AviSource() that I consider to be a multi threading issue, please find attached examples. DirectShowSource does not produce these stripes. Both AviFileSource and OpenDMLSource produce them, always at the same place and with same length (I think), but not always all three, and not in a reproduceable manner when navigating through the clip.
My version is AviSynth 2.60 (CVS 20130425, ICL10). I think I observed it also with 2.6a4.

[Groucho2004]

I observe some black stripes with AviSource() that I consider to be a multi threading issue
My version is AviSynth 2.60 (CVS 20130425, ICL10). I think I observed it also with 2.6a4.
Neither of those are MT versions.

[bxyhxyh]

Mode 5 is the slowest, right?
So why this code is faster in Mode5
DirectShowSource("00067-1.m2ts", audio = false, fps = 24.0/1.001, convertfps = true)
Mode 2 - 22.73 fps
Mode 3 - 57.14 fps
Mode 4 - 16.28 fps
Mode 5 - 73.19 fps
Mode 6 - 81.14 fps

[LigH]

A more urgent question back: Why DirectShowSource(convertfps=true)? Did all better ways fail?

[bxyhxyh]

A more urgent question back: Why DirectShowSource(convertfps=true)? Did all better ways fail?
Audio did not synced.

Edit:
I've 2 choices to rip this bluray.
1. DGAVCIndex
2. DirectShowSource
FFVideoSource and dss2 are not working properly for this video.

So I'm testing that which one is the fastest.

[LigH]

Well, as you proved, mode 5 will not always be the slowest "per-se". In your case, there will be reasons that it gets faster, possibly because it buffers more to avoid forth-and-back-jumping in the source harder? I am not the expert about the theory, but your practical example proved an exception.

I believe there is room for improvement by using Prefetch or LinearRequest. And possibly even more if you use an AviSynth native source filter (possibly after transmultiplexing the MTS to MKV first) and synchronizing functions of AviSynth. But that is a matter of the specific source, hard to help without more details.

Qualitywise, using DirectShow framerate conversion is probably the worst. There may be only one reason to need it, for variable framerate; but Blu-ray and MTS doesn't support VFR, so that won't be the reason.

FFMS2 doesn't support MTS well, you would have to convert it to MKV first. L-SMASH Source (LWLibavVideoSource / LWLibavAudioSource) may support it better. Still, a conversion to MKV first may solve many issues a priori.

[Groucho2004]

DirectShowSource("00067-1.m2ts", audio = false, fps = 24.0/1.001, convertfps = true)
Is that your entire script? What filters are you planning to use?

[bxyhxyh]

Is that your entire script?
For this test to choose fastest possible source filter, Yes

What filters are you planning to use?
I'm going to use prefiltered smdegrain and lsfmod
pre = last.fft3dfilter(sigma = 10, bw = 16, bh = 16, ow = 8, oh = 8, plane = 4).Gradfun3()
smdegrain(overlap = 16, blksize = 8, thsad = 500, lsb = false, pel = 2, refinemotion = true, chroma = true, truemotion = false, tr = 3, prefilter = pre, plane = 4)
lsfmod(strength = 150)

[martin53]

Neither of those are MT versions.
Hi,
please advise where I should post better, feel it might go unnoticed. EDIT this is not not say I insist it's related to multi-threading. I just know of no other V2.60 thread and I never saw that when I still used V2.58.

[Groucho2004]

Hi,
please advise where I should post better, feel it might go unnoticed.
I don't know what makes you think your problem is related to multi-threading considering that you are using a Avisynth DLL that does not support it.
You should probably post here (http://forum.doom9.org/forumdisplay.php?f=33).

[IanB]

@martin53,

Yes you should create your own thread in the Avisynth Usage (http://forum.doom9.org/forumdisplay.php?f=33) forum.

This is probably going to be a codec/decoder problem. So documenting which format and what codec's are involved is probably going to be helpful.

AviSource uses only VFW codecs, DirectShowSource uses the DirectShow infrastructure.

[Octo-puss]

I can't seem to get this mod to work.
I can't load any script, and am getting "there is no function named setmtmode" error.
I did replace the main dll in syswow64 folder.

Any help appreciated.

[Groucho2004]

I can't seem to get this mod to work.
I can't load any script, and am getting "there is no function named setmtmode" error.
I did replace the main dll in syswow64 folder.

Any help appreciated.
The error message means that you're not using the MT DLL. You probably have some old Avisynth DLL sitting in a folder to which the path environment variable points. Just search your local drives for avisynth.dll and delete all but the one you want to use.

[Octo-puss]

You were right. I missed one instance in main MEGui folder, probably left there from ages ago. It works fine now.

[andybkma]

Greets, Win7 64bit SP1, i7-3610QM, newest 2.6 MT 20130928

Is there a trick (config setting) to prevent the media player (in my case Zoom Player) from crashing when using the multi-threading of this avisynth.dll? 5 out of 10 times when starting a vid being real-time postprocessed with a sharpener (LSFMod for SD or FineSharp for HD) it crashes the media player. I never had this problem (ever) when not using the multi-threaded version. Using mt-masktools-26 2.0.48.0, RemoveGrain SSE3, Repair SSE3. Thanks ;-)

My settings for SD:

SetMemoryMax(512)
SetMTMode(2,4)
ffdshow_source()
SetMTMode(2)
LSFMod(defaults="fast",ss_x=1.5,ss_y=1.5,preblur="on")
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

My settings for HD:

SetMemoryMax(512)
SetMTMode(2,4)
ffdshow_source()
SetMTMode(2)
FineSharp()
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

[andybkma]

Try using mode 3 or mode 5 on source filter instead of mode 2.

Thanks, are you talking about changing SetMTMode(2,4) to SetMTMode(3or5,4)? I did that but same problem. Actually made the crashing worse ugh

[ryrynz]

Thanks, are you talking about changing SetMTMode(2,4) to SetMTMode(3or5,4)? I did that but same problem. Actually made the crashing worse ugh

Use SetMTMode(3) instead of SetMTMode(2,4)

[turbojet]

This goes back a year or more now but I vaguely remember FineSharp() randomly crashing on anything but SetMTmode(5) and not using MTmode was less cpu.

Also lower setmemorymax reduced the occurrences, think I settled with 128.

[andybkma]

This goes back a year or more now but I vaguely remember FineSharp() randomly crashing on anything but SetMTmode(5) and not using MTmode was less cpu.



Cheers for the tips, would like to try out to use this version of avisynth.dll in non-MT with FineSharp to compare but having problems with what code to use in ffdshow raw to get FineSharp to actually run in non-multithread mode. The first page doesn't say how to use scripts in non-MT mode with this version DLL. I put the same code in ffdshow raw that I had used with the original non-MT version of Avisynth but it didn't work. Could you perhaps please tell me what to put there in ffdshow for that? Cheers...

[andybkma]

Use SetMTMode(3) instead of SetMTMode(2,4)

Thanks for the tip, so I am assuming that SetMTMode(3) would be the same as SetMTMode(3,0) in that the default number of threads would be used (in my case 8). Am I correct in this? One side effect I am seeing by setting it to just (3) or (2) is that the videos take much longer to start playing than by setting it to (3,4) or (2,4). Am wondering if this is because 8 threads is just too much for this purpose and 4 makes it faster....

[ryrynz]

Correct. SEt states that MTmode 3 should be used before ffdshow_source(), I do wonder if this is the cause of your problems.
What you could also do it dropping the SetMTMode(2) if it still causes issues, that way you're in mode 3 through the whole process except for the end.
If you have no joy with that then I'd try the other suggestions above (Soothe=false and Maxmem setting, maybe mode 5)

So you want to try this:

SetMemoryMax(512)
SetMTMode(3)
ffdshow_source()
SetMTMode(2)
FineSharp()
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

and

SetMemoryMax(512)
SetMTMode(3)
ffdshow_source()
FineSharp()
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

[Groucho2004]

would like to try out to use this version of avisynth.dll in non-MT with FineSharp to compare but having problems with what code to use in ffdshow
Simply omit the *MTMode() statements.

[andybkma]

Simply omit the *MTMode() statements.

Thanks, I tried that which leaves me with this code:

SetMemoryMax(128)
ffdshow_source()
FineSharp()
or LSFMod()

But then I get error "Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE.

If I replace the MT avisynth.dll back to the original (non-MT) one in the SysWow64 folder then all is fine with the above code. So something is not right with the above code with the MT version of avisynth.dll to make it run in non-MT...

[Groucho2004]

But then I get error "Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE.
Try with this version (http://forum.doom9.org/showpost.php?p=1619023&postcount=649) of Masktools.

[andybkma]

Try with this version (http://forum.doom9.org/showpost.php?p=1619023&postcount=649) of Masktools.

Thank you kindly, that did it

[andybkma]

Correct. SEt states that MTmode 3 should be used before ffdshow_source(), I do wonder if this is the cause of your problems.
What you could also do it dropping the SetMTMode(2) if it still causes issues, that way you're in mode 3 through the whole process except for the end.
If you have no joy with that then I'd try the other suggestions above (Soothe=false and Maxmem setting, maybe mode 5)

So you want to try this:

SetMemoryMax(512)
SetMTMode(3)
ffdshow_source()
SetMTMode(2)
FineSharp()
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

and

SetMemoryMax(512)
SetMTMode(3)
ffdshow_source()
FineSharp()
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last


Thank you all for trying to help this noob to MTavisynth out. So lowering the SetMemoryMax to (128) from (512) seemed to have helped out my crashing ZoomPlayer at video start. So I went ahead and compared CPU usage and the rendering stats with mVR using the MT and the non-MT orig version and to be honest I don't see a bit of difference with either FineSharp() or LSFMod(). So am wondering if this MT avisynth version is for much heavier scripts than these two sharpeners or perhaps when combining multiple scripts?

[Groucho2004]

So am wondering if this MT avisynth version is for much heavier scripts than these two sharpeners or perhaps when combining multiple scripts?
Pretty much, yes. QTGMC() or some heavy de-noising functions do benefit from multi-threading.
If you want to experiment further, you might want to use this (http://forum.doom9.org/showthread.php?t=165528) to test scripts.

[real.finder]

about crashing, in the last version (2013.09.28), became occur randomly and without an appointment

and if it occurred, and after the re-run encoding again even without modifications, may work without crashing, or it occurred in other frame

that a side, for me, almost every filter work fine with mode 2, even Lsfmod

[Overdrive80]

Hi, actually I am getting random BSOD when encoding using Avisynt MT after updating operating system to windows blue. I have tried encoding without MT and system is stable. Excuse me but I'm not sure if it could be related. Would be it?

[Boulder]

You could try debugging the dump, but I would first try testing the system stability with stuff like Prime95 or LinX.

[SEt]

User mode apps must not even have rights to crash your system. So anything but Avisynth is to blame here (drivers? OS? hardware?). It's quite trivial that without MT your system is more stable: because way less system resources are used.

As already suggested, test system stability with apps like LinX and Prime95. Heavy modern games are also good for load tests (if you are not extremely GPU-bound there).

[Overdrive80]

You could try debugging the dump, but I would first try testing the system stability with stuff like Prime95 or LinX.

I have seen minidumps and are caused by different reasons. Here minidumps (https://dl.dropboxusercontent.com/u/19135067/Minidumps.7z)

User mode apps must not even have rights to crash your system. So anything but Avisynth is to blame here (drivers? OS? hardware?). It's quite trivial that without MT your system is more stable: because way less system resources are used.

As already suggested, test system stability with apps like LinX and Prime95. Heavy modern games are also good for load tests (if you are not extremely GPU-bound there).

I have tested system with LinX without BSOD.

http://img833.imageshack.us/img833/9652/8m5x.png

I apologize because I dont want to turn the thread into offtopic but only happens to me if I run with MT.

EDIT: All drivers is updated.

[Groucho2004]

I have tested system with LinX without BSOD.
LinX also doesn't produce BSODs.

[Boulder]

Did you give LinX the maximum amount of memory available? And you should also run it for several hours, I've seen it calculate an incorrect result after it had already been running the whole previous night.

[real.finder]

Hi, actually I am getting random BSOD when encoding using Avisynt MT after updating operating system to windows blue. I have tried encoding without MT and system is stable. Excuse me but I'm not sure if it could be related. Would be it?

use 2013.03.09 build instead of 2013.09.28

I also had stability problems in latest version

[Overdrive80]

Did you give LinX the maximum amount of memory available? And you should also run it for several hours, I've seen it calculate an incorrect result after it had already been running the whole previous night.

After of 14 hours I didnt get any error (https://dl.dropboxusercontent.com/u/19135067/LinX%2029-11-2013%2021-43-10.log).

use 2013.03.09 build instead of 2013.09.28

I also had stability problems in latest version

Thanks, I will test it.


EDIT: I can confirm that real.finder said, my system has become stable with previous version of MT.

[Overdrive80]

Excuse me, I hope that you can help me. Since days ago I get errors with avisynth like this:

http://imagizer.imageshack.us/v2/800x600q90/268/y7ws.png

I use windows 7 x64, I dont undertand why show "C\Windows\system32\avisynth.dll" if this *.dll is in syswow64.

I attach script. I would attach crash file of vdub if is required. Thanks.

[Guest]

When you have a complex script like that, you have to strip it down and then add stuff back step by step to see what causes the crash.

[ultim]

http://imagizer.imageshack.us/v2/800x600q90/268/y7ws.png

Based on the casing of the DLL (AviSynth.dll vs. avisynth.dll) I think you have AviSynth+. In this case please post to the AviSynth+ thread instead of here next time.

[Overdrive80]

When you have a complex script like that, you have to strip it down and then add stuff back step by step to see what causes the crash.

Ok, I will do. Is curious, I dont get this error if I remove the line: SetMTMode(x,y). O_O.

For you say, I understand that maybe some filter is looking for avisynth in wrong directory, dont it?

Thanks.

Based on the casing of the DLL (AviSynth.dll vs. avisynth.dll) I think you have AviSynth+. In this case please post to the AviSynth+ thread instead of here next time.

Nop, I use avisynth MT of SEt. But thanks for your interest.

[Guest]

MT is a hit or miss kind of thing. I never use it so can't help you, but others that use it may weigh in.

[TheSkiller]

I get this error (access violation) too, using the latest AviSynth 2.6 alpha 5 and SEt's MT. It didn't ever happen before.
To me the error seems to occur quite randomly upon loading scripts. Sometimes I reload the script in VirtualDub (F2 Key) and get the error, then I reload again and it works... Sometimes it's there 10 times in a row. Sometimes it won't stop. I cannot nail it down to a specific script line.

[SamKook]

Is curious, I dont get this error if I remove the line: SetMTMode(x,y). O_O.

Try with SetMTMode(5,4) instead of 6,4 for the first one. I don't remember if mode 6 is stable or not, but I chose to use 5 myself instead so there probably was a good reason.

[qyot27]

This was covered with a big discussion in another thread (I think it was the 2.6a4 thread? maybe it was the 2.6 MT thread) - if you're using SEt's MT build, you are not using the official 2.6a5. Only one avisynth.dll is used at any one time, and if you're using SEt's, the avisynth.dll is SEt's, not the official one. If you switch back and forth between them and it happens in both, then that's one thing, but if it only happens when SEt's is used, that's something to report over in the 2.6 MT thread, not here.

Remember, mind your dlls.

[Overdrive80]

I get this error (access violation) too, using the latest AviSynth 2.6 alpha 5 and SEt's MT. It didn't ever happen before.
To me the error seems to occur quite randomly upon loading scripts. Sometimes I reload the script in VirtualDub (F2 Key) and get the error, then I reload again and it works... Sometimes it's there 10 times in a row. Sometimes it won't stop. I cannot nail it down to a specific script line.

I have the same problem with vdub.

Try with SetMTMode(5,4) instead of 6,4 for the first one. I don't remember if mode 6 is stable or not, but I chose to use 5 myself instead so there probably was a good reason.

I try mode 6 because with 5 get this error too.

This was covered with a big discussion in another thread (I think it was the 2.6a4 thread? maybe it was the 2.6 MT thread) - if you're using SEt's MT build, you are not using the official 2.6a5. Only one avisynth.dll is used at any one time, and if you're using SEt's, the avisynth.dll is SEt's, not the official one. If you switch back and forth between them and it happens in both, then that's one thing, but if it only happens when SEt's is used, that's something to report over in the 2.6 MT thread, not here.

Remember, mind your dlls.

Ok, please moderators, could move this part of thread to MT´s SEt (http://forum.doom9.org/showthread.php?t=148782) for not disturb to some users. Thanks and excuse me.

[Guest]

Ok, please moderators, could move this part of thread to MT´s SEt (http://forum.doom9.org/showthread.php?t=148782) for not disturb to some users. Thanks and excuse me. Done and bumped. :)

[SEt]

The first thing that comes to mind: memory consumption. How much virtual memory the process allocated when you see that crash?
And the N'th time: source filters should use MTMode 3 by default.

[LigH]

Regarding your 64-bit Windows and system32 vs. SysWoW64:

Yes, you should use the 32-bit AviSynth MT, which will be put into C:\Windows\SysWoW64; but the 32-bit AviSynth MT will only be used by a 32-bit application. A 64-bit application will try to use a 64-bit (original) AviSynth in C:\Windows\system32. But 64-bit AviSynth is notorious for being unstable and not having many 64-bit plugins available. And I don't remember a 64-bit AviSynth MT to exist.

To use a 64-bit application (e.g. a 64-bit build of the x264 encoder) together with a 32-bit AviSynth MT, you have to use a 32-bit piping tool (e.g. avs4x264mod) which takes the video output from the 32-bit AviSynth MT and forwards it into the 64-bit x264 via a file pipe. Regarding VirtualDub, you should run a 32-bit version of it.

[Overdrive80]

The first thing that comes to mind: memory consumption. How much virtual memory the process allocated when you see that crash?
And the N'th time: source filters should use MTMode 3 by default.

If I use MTMode 3, directly vdub crash. For this reason, I had used MTMode 5 or 6, until now.

Memory consumption was between 1000-1024 mb.

Regarding your 64-bit Windows and system32 vs. SysWoW64:

Yes, you should use the 32-bit AviSynth MT, which will be put into C:\Windows\SysWoW64; but the 32-bit AviSynth MT will only be used by a 32-bit application. A 64-bit application will try to use a 64-bit (original) AviSynth in C:\Windows\system32. But 64-bit AviSynth is notorious for being unstable and not having many 64-bit plugins available. And I don't remember a 64-bit AviSynth MT to exist.

To use a 64-bit application (e.g. a 64-bit build of the x264 encoder) together with a 32-bit AviSynth MT, you have to use a 32-bit piping tool (e.g. avs4x264mod) which takes the video output from the 32-bit AviSynth MT and forwards it into the 64-bit x264 via a file pipe. Regarding VirtualDub, you should run a 32-bit version of it.

I dont use avisynth 64bits neither virtualdub 64 bits. I use version 32 bits of SEt, virtualdub 32 bit and plugins of 32 bits. I dont use filters neither programs of differents arquitectures. Only use OS of 64 bits because I have 6GB ram.

EDIT: Crash virtualdub: http://pastebin.com/qbFs2Q7c

[SEt]

You are crashing inside AVIReadStream::Read, no idea why though. And it looks like 2013.03.09 version – have you tried 2013.09.28?

[ultim]

VirtualDub may crash after F2 because wrong COM model is used. Avisynth MT requires CoInitializeEx(nil, COINIT_APARTMENTTHREADED) not COINIT_MULTITHREADED - memory leak is occured when create a new DirectShow graph instead of old used. Use Windmotion PlayEdit instead. It has memory use indicator and correctly frees old DirectShow graph.

You have too many trim and complex scripts. It produces too many cache entries and memory usage, so you probably have 2GB memory limit override. There is no checks at all.

I'm not very familiar with COM, so maybe somebody can help me out. What if I deleted the COM initilaization inside AVs+ core, and left that task completely to the host application? Would that break existing apps? Or would it have any other disadvantages?

[Overdrive80]

You are crashing inside AVIReadStream::Read, no idea why though. And it looks like 2013.03.09 version – have you tried 2013.09.28?

Nop, I am using 2013.03.09 version because in win 8.1 would get ramdom BSOD. I try this version in this system.

VirtualDub may crash after F2 because wrong COM model is used. Avisynth MT requires CoInitializeEx(nil, COINIT_APARTMENTTHREADED) not COINIT_MULTITHREADED - memory leak is occured when create a new DirectShow graph instead of old used. Use Windmotion PlayEdit instead. It has memory use indicator and correctly frees old DirectShow graph.

You have too many trim and complex scripts. It produces too many cache entries and memory usage, so you probably have 2GB memory limit override. There is no checks at all.

Ok, when I remove of file´s head:

SetMemorymax(1024)
SetMtMode(3,4)

Not occurs any crash even use SetMTMode(2) in below lines of script.

Thanks.

[Boulder]

When you remove the SetMTMode line, you also disable multithreading.

[Overdrive80]

Bad way for complex scripts. In some cases we need 2 threads and even complete disable threading to prevent 2GB memory limit. Try to decrease thread count first then decrease memory by /2 before you get stable values.

But very best way is to divide your complex script for two or more separately scripts and pipe them or create temporary file using UtCodec or other encoder.
Or do not use Avisynth MT...

Thanks, I think that will not use MT.

[Dogway]

But very best way is to divide your complex script for two or more separately scripts and pipe them

how do you pipe-concatenate 2 or more scripts on chain? I haven't seen this yet. Or did you mean filtering in parallel?

[innocenat]

You can do TCPSource/TCPDeliver across two scripts though, bit it's kinda hackish.

[martin53]

You can do TCPSource/TCPDeliver across two scripts though, bit it's kinda hackish.

To my experience, if one script is called from a x86 viewer app, then they share a common 2GB memory space. Does one of the scripts (the delivering one supposedly) with the TCPDeliver approach have its own 2GB memory???

[innocenat]

To my experience, if one script is called from a x86 viewer app, then they share a common 2GB memory space. Does one of the scripts (the delivering one supposedly) with the TCPDeliver approach have its own 2GB memory???

Use it from two different application, or multiple instance of single optimization. Have you read about TCPServer (sorry, it's not TCPDeliver, I remember it wrong)? You can even do it over two different machine.

[real.finder]

Overdrive80

try to remove SETMTmode(6,4) and use SoraThread or ThreadRequest after source call, then use Setmtmode, like:-


LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")

avisource("E:\DB Movies\DSSD10372\Pelicula 02\Funi\0. Srestore.avi").ThreadRequest(10, 5) # or SoraThread

#Ajuste inicial de frame count
last=trim(44,0)

#Ajuste de metrica
last=trim(0,18571)++trim(18571,18571)+trim(18572,0)
last=trim(0,18572)++trim(18504,18504)++trim(18504,18505)++trim(18573,0)
last=trim(0,18575)++trim(18575,0)
last=trim(0,18576)++trim(18568,18570)++trim(18577,0)
last=trim(0,18578)++trim(18578,18579)++trim(18580,0)
last=trim(0,18580)++trim(18580,18580)++trim(18580,18580)++trim(18581,0)
last=trim(0,18582)++trim(18574,18574)++trim(18574,18574)+trim(18583,0)
last=trim(0,18584)++trim(18564,18564)++trim(18564,18564)++trim(18564,18564)++trim(18585,0)
last=trim(0,18587)++trim(18563,18563)++trim(18563,18563)++trim(18563,18563)++trim(18588,0)
last=trim(0,18590)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18591,0)
last=trim(0,18596)++trim(18625,18631)++trim(18597,0)
last=trim(0,18596)++trim(18597,18597)++trim(18597,0)
last=trim(0,18606)++trim(18606,0)
last=trim(0,40993)++trim(40944,40972)++trim(40998,0)
b=trim(58600,58600)
last=trim(0,58600)++b++b++b++b++b++b++b++b++b++b++b++b++b++b++b++trim(58601,0)
last=trim(0,58615)++trim(58624,58642)++trim(58624,0)
last=trim(0,framecount()-132)

Setmtmode(2)

spline36resize(720,480,src_left=8, src_top=0, src_width=-5, src_height=0)

#Para controlar el aspect ratio: .subtitle(string(last.aspect_error(8,0,-6,-0))) Antes del crop

###################################
# FILTRADO #
###################################

original=last

>>>>>>>>>>>>>>>> etc...


and if you want to use all memory of your system try mp_pipeline

SEt, try add GetProcessMemoryInfo memory checks to Avisynth buffer memory allocate code to prevent new cache item create after 2GB or 3GB if LARGEADDRESSAWARE is used. It may fix 50% Avisynth MT crashes.

Yes, after the new cache in Alpha 5 (2013.09.28 build), there are many problems of stability

[Overdrive80]

Overdrive80

try to remove SETMTmode(6,4) and use SoraThread or ThreadRequest after source call, then use Setmtmode, like:-

[CODE]
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")

avisource("E:\DB Movies\DSSD10372\Pelicula 02\Funi\0. Srestore.avi").ThreadRequest(10, 5) # or SoraThread



Thank you, I will try it.

[MichaelRow]

I've got a problem about MT. I don't know how to let MT make full use of my computer since the CPU is at about 50% capacity.
Here's the script:
SetMTMode(2,8)
SetMemoryMax(1300)
source=LWLibavVideoSource("D:\04.m2ts")
denoised=source.SMDegrain(thSAD=200, thSADC=50, prefilter=0, tr=3, plane=4, RefineMotion=true)
line=denoised.mt_edge("min/max").mt_deflate()
debanded=denoised.GradFun3(radius=17,radiusc=17,thrc=0.35,thr=0.35, smode=2)
Final=mt_merge(debanded, source, line, luma=true)
return Final

[LigH]

Not sure if it applies here, because it should not really be the bottleneck; just in general: It is recommendable to run the *Source plugin with MT mode 3 or 5 (depending on the specific decoder) and switch to mode 2 afterwards, so the decoder is only called once, not as many times as threads are used. Especially when the decoder itself may be multithreaded.
SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
# ...

Also check if the encoding process makes use of the pagefile. Not very likely if you have enough RAM, nevertheless that would be a serious bottleneck if it was the case.

[Boulder]

My guess is that SMDegrain is quite complex so it's not very efficiently split between different threads.

[Groucho2004]

I wonder if "yuv4mpegpipe" adds the necessary Distributor() call. If not, the frames would probably be piped single threaded into x264.

[SamKook]

I know avs2pipemod which is similar doesn't add distributor() so I'd say it's likely the problem.

[qyot27]

I wonder if "yuv4mpegpipe" adds the necessary Distributor() call. If not, the frames would probably be piped single threaded into x264.
The libavformat AviSynth demuxer (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avisynth.c) (which is what would be responsible for it, rather than yuv4mpegpipe) has no special-casing for MT builds, so no.

[MichaelRow]

Thank you all
Not sure if it applies here, because it should not really be the bottleneck; just in general: It is recommendable to run the *Source plugin with MT mode 3 or 5 (depending on the specific decoder) and switch to mode 2 afterwards, so the decoder is only called once, not as many times as threads are used. Especially when the decoder itself may be multithreaded.
SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
# ...

Also check if the encoding process makes use of the pagefile. Not very likely if you have enough RAM, nevertheless that would be a serious bottleneck if it was the case.
It doesn't improve much. As for RAM, there's 800M of 4G free.


My guess is that SMDegrain is quite complex so it's not very efficiently split between different threads.
Not. SMDegrain() is a simple funtion based on MDegrain, and it can work well with other filters when going mutithread.


I wonder if "yuv4mpegpipe" adds the necessary Distributor() call. If not, the frames would probably be piped single threaded into x264.
I know avs2pipemod which is similar doesn't add distributor() so I'd say it's likely the problem.
The libavformat AviSynth demuxer (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avisynth.c) (which is what would be responsible for it, rather than yuv4mpegpipe) has no special-casing for MT builds, so no.
Yes, that's the problem. When using x264(32bit) to open avs script and encode, the CPU Occupancy can reach 90% and above, but half of the occupancy when use ffmpeg(32bit) piping to x264(64bit). I don't know much about Distributor() and libavformat AviSynth demuxer, and could you describe how to solve the problem when piping in detail? Thanks again.

[Groucho2004]

I don't know much about Distributor() and libavformat AviSynth demuxer, and could you describe how to solve the problem when piping in detail?
Try this script:


SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
denoised=source.SMDegrain(thSAD=200, thSADC=50, prefilter=0, tr=3, plane=4, RefineMotion=true)
line=denoised.mt_edge("min/max").mt_deflate()
debanded=denoised.GradFun3(radius=17,radiusc=17,thrc=0.35,thr=0.35, smode=2)
mt_merge(debanded, source, line, luma=true)
GetMTMode(false) > 0 ? Distributor() : last

[qyot27]

EDIT: I was too slow, but anyway...

If the application (in this case, ffmpeg) doesn't automatically add Distributor(), then the user has to add it themselves, at the end of their script.

Whether the pipe will end up playing a role here, I don't know.

[MichaelRow]

Try this script:


SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
denoised=source.SMDegrain(thSAD=200, thSADC=50, prefilter=0, tr=3, plane=4, RefineMotion=true)
line=denoised.mt_edge("min/max").mt_deflate()
debanded=denoised.GradFun3(radius=17,radiusc=17,thrc=0.35,thr=0.35, smode=2)
mt_merge(debanded, source, line, luma=true)
GetMTMode(false) > 0 ? Distributor() : last


It does work,but ffmpeg (as well as avs2yuv) would crash with a error message "ffmpeg has encountered a problem and needs to close" several minutes after the encoding begin.

Whether the pipe will end up playing a role here, I don't know.

Seems that your concern is well-founded.

[Groucho2004]

It does work,but ffmpeg (as well as avs2yuv) would crash with a error message "ffmpeg has encountered a problem and needs to close" several minutes after the encoding begin.
You're probably running out of memory. Reduce the number of threads.
Check how much memory your script needs with this tool (https://forum.doom9.org/showthread.php?t=165528).

To maximize available memory for the frame serving and encoding on a 64 Bit OS you should use a pipe tool that has the "LARGEADDRESSAWARE" linker flag set and pipe the output to a 64 Bit version of x264. This way the frame server can allocate almost 4 GB.

[Doom9]

7 posts from the tail end were removed because they intermixed technical arguments with personal and went on to violate the forum rules. Cleaning them up would've required significant rewrites that would most likely have fundamentally changed what the posters meant to say - so in order not to put words in anybody's mouth, I removed the entire exchange (as per the moderator rules all content is still here, just invisible).
And I'd like to remind everybody that this is a forum for technical discussion, not personal bickering and attacks. If you don't agree with somebody on a technical level, you need to back up your argument with facts, not just dismiss somebody's opinion off hand as invalid, pointless, or whatever other term you can find to infuriate the guy on the other line.
Also, we have an established way to settle disagreements and it's not duking it out here in the forum.

Sorry for the OT post.

[GMJCZP]

I have problems using VSFilter, the subtitles sometimes display wrong. I have found it by using SetMTMode. To remedy this (apparently working) I had to use this:

.
.
.
SetMTMode (5,2) #already used in source filters (!), use 5 or 3 is indifferent
TextSub (...)
SetMTMode (2,2) #already used in others filters
.

What I can do for normal operation with vsfilter?

I'm using the latest versions of avisynth and set mt. Thank you.

[SamKook]

If the change you made fixed it, then it simply means that vsfilter doesn't support MT mode 2 properly so you can either do what you did or change to another subtitle renderer.

BTW, you should only specify the number of threads to use the first time with SetMTMode so the second call should only be SetMTMode(2).

[GMJCZP]

If the change you made fixed it, then it simply means that vsfilter doesn't support MT mode 2 properly so you can either do what you did or change to another subtitle renderer.

BTW, you should only specify the number of threads to use the first time with SetMTMode so the second call should only be SetMTMode(2).

I ran what I did, I can confirm. I hope someone will serve this.

Yes, only put SetMTMode (2) is sufficient, Thanks. Hopefully people VSFilter check that error.

[Seedmanc]

Which Avisynth 2.6 am I supposed to use with spatial MT("")? It keeps telling me that I need to use 2.6 or 2.5.7mod, but I do have 2.6 already I think (the alpha one), while 2.5.7 is too old for me. I need spatial MT because temporal introduces too much lag for realtime processing.

[Groucho2004]

Which Avisynth 2.6 am I supposed to use with spatial MT("")? It keeps telling me that I need to use 2.6 or 2.5.7mod, but I do have 2.6 already I think (the alpha one), while 2.5.7 is too old for me. I need spatial MT because temporal introduces too much lag for realtime processing.
The last version that supports the MT() plugin is this one (http://forum.doom9.org/showthread.php?t=148117).

[GMJCZP]

I do not know if anyone has happened to use SetMTMode that processing speed decreases. Is it possible to happen?

[Groucho2004]

I do not know if anyone has happened to use SetMTMode that processing speed decreases. Is it possible to happen?
I could probably come up with a script that would achieve that but have not tried yet.
Disregarding some or all hints/instructions from the first post is a good point to start.

[GMJCZP]

@ Groucho2004

Aside from scientific research (which never hurts, :thanks: ), I said it because it is happening to me without looking!

I usually use two scripts, one for heavy duty with Lagarith and the other for final work with debanding (due to clean in the first script) and I had the rude awakening that it was better to run without SETMTMode.

Fortunately I managed to purify itself and the second script worth using MT but I still have problems with the first. In this process, as happened with penicillin, discovered inadvertently a Deblock_QED small correction:

Here (http://forum.doom9.org/showthread.php?p=1697386#post1697386)

I notice that the FPS (in VirtualDub / VirtualDubMod) are more stable without SetMTMode, instead FPS with him is a seesaw of madness.

[Groucho2004]

I notice that the FPS (in VirtualDub / VirtualDubMod) are more stable without SetMTMode, instead FPS with him is a seesaw of madness.
Extreme fluctuations in processing speed are normal with Avisynth MT. All that matters is the average speed. A good insight as to how your script behaves can be provided with AVSMeter (http://forum.doom9.org/showthread.php?t=165528).

[LigH]

It will certainly depend on the specific MT mode. There are source filters which work well with one MT mode because their decoders are programmed very clean and stable (e.g. using only a local set of variables to be independent from the calling environment, a.k.a. "re-entrant"), and others which require a different MT mode because they are not well prepared for working in a multi-threaded environment and need to be protected from their copies in other threads. In case of AviSource, even different VfW codecs may behave more or less convenient, up to a point where they only work reliably with a sequential request of frames.

Therefore, or furthermore, it may help to use Preroll(#) – an additional frame buffer, similar to RequestLinear(), to avoid the decoder jumping backwards if several threads work with frame numbers of a larger distance.

[GMJCZP]

Groucho2004, LigH, thanks for your comments.

Groucho2004, I have not used your program, sooner or later I will use.

LigH, did not know the Preroll function but do not know exactly how it works, I am ashamed to say that looked more like an intruder in my script as a function.

But finally I found the reason why it took more time of processing using SetMTMode: RemoveGrainSSE2.dll
If you are using RemoveGrainSSE3.dll everything is solved, the reason why SSE2 is used because it seemed to read that could cause crashes.
I took it out because if you import a function that calls the dll, but do not use it then you would realize ever, so my second script refined worked fine.

Mystery solved and as the ending music is heard "Scooby Doo, Where are you" ...


Final note: I actually solved two mysteries, If using K-Lite is better installing separately Xvid of Jawor. K-Lite_Codec_Pack_1080_Mega active postprocessing by default, affecting the image and probably increasing the processing time of AviSource.

[LigH]

In general, never use "Codec Packs". Install only the codecs or filters you really need, only from the original author (if possible; or from trustworthy archives). Some codec packs are not completely legal; some codec packs even alter Windows interna which may have side effects, even after uninstalling them.

Just for playback, there are only few formats LAV Filters do not yet support. And for processing AVIs via VfW, you will only need very few additional codecs; ffdshow still contains a lot of VfW decoders. And L-SMASH Works can handle AVIs too, to make VfW nearly obsolete for decoding.

Preroll() will get the video decoded several frames ahead in sequential order and buffers a range of decoded frames. This helps avoiding a decoder to have to go backwards, which often means it has to decode the whole sequence from a previous keyframe to the current position. Backward jumps in a decoder may happen when a video is processed with multiple threads, and one thread is ahead of another.

[GMJCZP]

I've had two crashes due to use first SSE3 and then version of RemoveGrain 1.0pre. I think the SS2 he used was that of Vit.
Now I'm trying RGTools, just to see if it does not hang, but tp7 says the results are almost identical to the previous versions, so I do not want to use. If please recommend me while SetMTMode functional stable version, that is, it does not slow down the processing.

LigH, I will see with lavfilters (nevcairiel). ffdshow still have updates?
What is Lsmash? Sorry for my ignorance.

About Preroll() in which part of the script goes, what then of SetMTMode(2)? Without parameters?

Update: Other crash more, with rgtools, but the message of error now says about frfun3d. I need help.

[Boulder]

It could be that the script just is too complex and it's going to be almost if not impossible to make it work with multithreaded Avisynth.

There are ways around that - split encode into multiple parts and encode them simultaneously as lossless intermediate files in single threaded mode, then combine them in the script for the final processing (debanding in your case). If you use MVTools2, use cretindesalpes's build as it is internally multithreaded. This process is what I always do with my QTGMC stuff.

[TurboPascal7]

Now I'm trying RGTools, just to see if it does not hang, but tp7 says the results are almost identical to the previous versions, so I do not want to use.

There is absolutely no reason to use RemoveGrain over RgTools unless you want exact script compatibility (some parameters like "cache" are not implemented). The minor rounding differences will not affect your output in any significant way (and might as well make it better). And it should work with any MT mode up to 1.

[GMJCZP]

@TurboPascal7:
Your observation clarifies my doubts, thanks.

@Boulder:
In recent years I have always used MVTools cretindesalpes's builds. Using your recommendation now I all went well, in fact that we discussed with AnimeIVTC and had already tried before, and thank you very much again.

Indeed, the crashing problem is perhaps because of its complexity. When used removegrainSSE2 slowed the process, causing the system to feel less committed than without SetMTMode, so not hung.

I was able to run the second script in MT without problems, but my concern now why that dll caused that MT was slower. In addition, there will be no other solution than the Boulder?

Note: simultaneously I used option RGBA in Lagarith for test and avoid more banding, this will cause more instability that YV12?

[LigH]

Converting forth and back between RGB(A) and YUV (any variant) in only 8 bit resolution will probably cause rounding errors and even introduce banding.

L-SMASH Works (http://forum.doom9.org/showthread.php?t=167435) is a project by VFR maniac which uses LAV Filters as splitters and decoders for AviSynth and VapourSynth; pseudo-mathematical similarity relation:

(DirectShow) ffdshow : LAV Filters ~ (AviSynth) FFMS2 : L-SMASH Works

FFMS2 has some known problems with MPEG related containers, explicitly prefers MKV; L-SMASH Works supports many containers without issues and even has specific support for ISO Media containers (a family which MOV and MP4 belong to).

There is only marginal "development" for ffdshow anymore, if at all...

And by the way, you still did not document which MT mode you preferred. There are differences between SetMTMode(2) or SetMTMode(3) or SetMTMode(5) or SetMTMode(6)... and different *Source filters should possibly be used with a different MT mode, e.g. DGDecNV may not work well in mode 2 due to its access to a decoder chip. Switching the MT mode after calling the *Source filter is quite common.

Regarding Preroll(), search this forum for threads containing "preroll requestlinear". This should return a few examples, comparing both (Preroll is native to the AviSynth MT kernel; RequestLinear is included in TIVTC). Either should follow the *Source function immediately, parameters will control the range of cached frames around the currently processed frame.

[GMJCZP]

Converting forth and back between RGB(A) and YUV (any variant) in only 8 bit resolution will probably cause rounding errors and even introduce banding.

Is better YV12, confirmed.

L-SMASH Works (http://forum.doom9.org/showthread.php?t=167435) is a project by VFR maniac which uses LAV Filters as splitters and decoders for AviSynth and VapourSynth; pseudo-mathematical similarity relation:

(DirectShow) ffdshow : LAV Filters ~ (AviSynth) FFMS2 : L-SMASH Works

FFMS2 has some known problems with MPEG related containers, explicitly prefers MKV; L-SMASH Works supports many containers without issues and even has specific support for ISO Media containers (a family which MOV and MP4 belong to).


Thanks for the information.


And by the way, you still did not document which MT mode you preferred. There are differences between SetMTMode(2) or SetMTMode(3) or SetMTMode(5) or SetMTMode(6)... and different *Source filters should possibly be used with a different MT mode, e.g. DGDecNV may not work well in mode 2 due to its access to a decoder chip. Switching the MT mode after calling the *Source filter is quite common.

Regarding Preroll(), search this forum for threads containing "preroll requestlinear". This should return a few examples, comparing both (Preroll is native to the AviSynth MT kernel; RequestLinear is included in TIVTC). Either should follow the *Source function immediately, parameters will control the range of cached frames around the currently processed frame.

I use SetMTMode(5), SourceFilters, SetMTMode(2), generally.
The problem for me, and if it helps with MT, which is part of the script and how parameters is used Preroll(). I have not got examples, perhaps because I now internet is difficult to use for long. :(

[LigH]

Here (http://forum.doom9.org/showthread.php?p=1629239#post1629239) is an example by IanB: "Preroll(video=25, audio=10.0)" (video in frames, audio in seconds).

BTW, Selur (author of "Hybrid") reports (http://forum.doom9.org/showthread.php?p=1631414#post1631414) that "Preroll(100)" (100 frames video, no specific value for audio) uses less RAM than "RequestLinear(rlim=50,clim=50)"; so there are two more examples (I am not sure if this syntax works). Just try different forms and values, and see if it affects speed and stability. Remember it needs more RAM for its own buffer, so you may have to reduce the demands of multithreaded parts slightly, e.g. reduce the number of threads a bit below the number of CPU cores.

RequestLinear is verbosely documented in an own text file inside the TIVTC (http://avisynth.nl/index.php/TIVTC) archive (TIVTCv105.zip (http://bengal.missouri.edu/~kes25c/TIVTCv105.zip)); Preroll is briefly documented in the AviSynth Wiki (http://avisynth.nl/index.php/Preroll).

[GMJCZP]

Thanks. Apparently you would like this:

SetMTMode (5)
Source ()
Preroll (arguments, play with option video)
SetMTMode (2)

[LigH]

Yes, and regarding the first line, depending on your CPU:

SetMTMode (5, threads)

Setting the number of threads is only valid in the very first use of SetMTMode. It is only recommendable if you have a high number of CPU cores, to avoid too many copies all using their own RAM in only 2 GB of a 32-bit process memory (only 2 GB if the calling program is not "Large Address Aware"; if it is LAA, up to 4 GB).

You don't need to reduce the number of threads if you only have a DualCore CPU, or up to QuadCore without HyperThreading. But with a HexaCore, or a QuadCore with HyperThreading (which virtually doubles the number of cores to 8), multithreading with 6 or even 8 threads (= copies of your script plugins) may take too much RAM and cause crashes.

[GMJCZP]

Yes, and regarding the first line, depending on your CPU:

SetMTMode (5, threads)

Setting the number of threads is only valid in the very first use of SetMTMode. It is only recommendable if you have a high number of CPU cores, to avoid too many copies all using their own RAM in only 2 GB of a 32-bit process memory (only 2 GB if the calling program is not "Large Address Aware"; if it is LAA, up to 4 GB).

You don't need to reduce the number of threads if you only have a DualCore CPU, or up to QuadCore without HyperThreading. But with a HexaCore, or a QuadCore with HyperThreading (which virtually doubles the number of cores to 8), multithreading with 6 or even 8 threads (= copies of your script plugins) may take too much RAM and cause crashes.

Naturally, include threads, in my case my PC is Core 2 Duo:
SetMTMode (5,2)...
Is valid your note about threads in other cases too.

[GMJCZP]

I just did a test using Preroll(video = 24) on my first script (fps VideoSource = 23.976) and not get hung up, this time I did not use frfun3d, which is very heavy (I added 1 hour processing).
Looks promising, as I had a crash before removing frfun3d.

We need more tests, using as a starting point and empirically Preroll(video = round(fps video source))

[Boulder]

There is something funny here, I just noticed some weird artifacts when encoding with x264. I was able to reproduce it by using this script and the sample clip. Sometimes there are no artifacts right after the scene change, but usually they are there. If I uncomment the RequestLinear line, I haven't been able to get the artifacts. You can use any settings in x264, they don't seem to have any effect. I use piping to feed to a 64-bit x264 executable, hence the Distributor call.

SetMTMode(5)
DGSource("convictiontest.dgi")
#RequestLinear(clim=100)
SetMTMode(2)
Bicubicresize(1280,688,b=-0.6,c=0.3)
Distributor()

Can anyone replicate this one?

Here's the sample: https://drive.google.com/file/d/0BzeF_1syecQwOVRLd09KQWxQZnM/view?usp=sharing

[Groucho2004]

Can anyone replicate this one?
Tried 3 times, can't reproduce it with your clip and script. Are these subtle artifacts or obvious ones?

[Boulder]

They are very obvious ones.

http://i.imgur.com/1s7exoql.jpg (http://imgur.com/1s7exoq)

It's possible that it's just my computer that shows the issue since MT is a tricky beast.. I did notice that it doesn't matter which MTMode is in use, if there's a Distributor call in the script, the artifacts appear (without RequestLinear).

The difficult thing is that I don't know if Avisynth or x264 is the one to blame:confused:

[LigH]

Don't use Distributor() except you are certain that the calling process needs it. One of the few places where it may be required is in the ffdshow postprocessing, but x264 does not need it.

[Groucho2004]

The difficult thing is that I don't know if Avisynth or x264 is the one to blame:confused:
If you get the artifacts by changing the script I suppose it's safe to assume that the problem is in your AVS -> pipe chain.

Are you using the latest AVS MT? Also, try this (https://www.dropbox.com/s/2w7ea8j1ppvwak2/avs2yuv.zip?dl=0) version of avs2yuv, it does not require the Distributor call in any case.

The RequestLinear() function uses a lot of memory, try increasing the default cache size from 512MB to 1024MB (SetMemoryMax).

[Boulder]

I've been using avs2pipemod for piping for years and that requires Distributor to make MT work, and yes, the latest build of AVS MT is in use. I'll test avs2yuv shortly..

EDIT: avs2yuv is more stable but not faultless :( Uncommenting RequestLinear still fixes the issue, the same goes for Preroll if the amount of frames is large enough (25 frames seems to suffice). SetMemoryMax is at 768MB at the moment.

[Groucho2004]

@Boulder
I assume that this is a purely academic exercise since your script certainly does not need speeding up with Avisynth MT, right?

[Boulder]

The script is simple as I worked my way down to the simplest form which would show the artifacts. My normal script has a custom made function for denoising etc. which is rather heavy duty. I just happened to notice those errors by accident when previewing stuff before moving it to my networked media player.

Actually I can reproduce it even with a simple

DGSource("convictiontest.dgi")
SetMTMode(2)
ConverttoYV12()

so it doesn't even need the resizing part. Changing the cropping in the index file also doesn't change the outcome.

[Groucho2004]

DGSource("convictiontest.dgi")
SetMTMode(2)
ConverttoYV12()
That script wouldn't even use multi-threading since it has no SetMTMode before the source filter.

[Boulder]

Sorry, I do have that one set as a default with an avsi file in my plugins folder along with the SetMemoryMax call. Saves time when writing the script ;)

[Sparktank]

@Boudler

Have you tried remuxing to MKV and using FFMS2 ?
(not sure if FFMS2 still has issues with transport streams, can't remember the exact issues it had but haven't really followed for over a year on FFMS2 and transport streams.)

EDIT: That IS DGdecNV.
Old DGdec uses MPEG2Source(). :p
Have you tried updating DGdecNV and/or your graphics card drivers?
NVidia just updated in the past week.

Also, taro_06 (aka Astrataro) has updated avs4x264 with bugfixes and new support for x265 and x262.
avs4x26x - Modified avs4x264
http://tmod.nmm-hd.org/avs4x26x/
"avs4x26x.exe" --x26x-binary "64_8.exe" -o "output.mkv" "script.avs"
Document says default binary is "x264_64", but I rename mine.

It's recently updated and pretty much stable.

[foxyshadis]

Boulder, what are your system specs? Maybe it's a specific issue with an instruction set, or the video card if you use DGDecodeNV.

[Boulder]

I'm running an i5-4670K with a GeForce 520-based videocard.

With that simple script, I was able to get the artifacts also when inputting the script directly in a 32-bit x264 so the next step must be eliminating DGDecodeNV out of the equation.

[Boulder]

I remuxed the transport stream to mkv and tried FFVideoSource. It seems that the artifacts are gone, however the output from x264 is not the exact same every time (based on the final bitrate). I don't know if this is due to the nature of FFVideoSource or x264 threading. The next thing I'm going to do is to experiment with various nVidia driver versions.

[huhn]

x264 with multi threading doesn't have a bit identical output so this should be your issue.

[Boulder]

Yes, I recall reading that sometime. The difference in bitrate was extremely small, less than one kbps. When the artifacts appeared, the difference was quite a bit larger ;)

The display driver versions don't affect the output so it looks like I'm going to have to live with it and use RequestLinear if anyone else is not able to reproduce it.

[Seedmanc]

Just my 2c here, I remember experiencing artifacting with DG-related stuff as well, especially with its NV-enabled part, it never works right, so I would vote for it being the cause.

As for identical output, I thought it's only non-identical if you're using --non-deterministic in arguments for x264, isn't it so? Maybe the gui/other program you're using to launch x264 adds it, just an assumption.

[GMJCZP]

I just did another test, this time using frfun3d and hung.
I had to code as suggested Boulder.
I do not know whether to use RequestLinear (), but do not know exactly how it is used, and if prevent more crashes. :confused:

@Boulder
Regarding your problem, I do not know about piping, but you know exactly which version of x264.exe are you using? This way someone could look into a repository and try to recreate your case (in CLI mode, maybe).
It is normal that the bitrate increases when appears such artifacts.

[l33tmeatwad]

Created a standalone installer that fully sets up AviSynth with the MT version included.

<LINK REMOVE DUE TO BEING OUTDATED>

Edit: Figured I would also point out I changed the "Play" option to open in MPC-HC and I fixed the problem where in windows 8 it won't properly display the icon in Add/Remove programs on x64 systems because of how it writes to the registry. It includes AVSTP in the installer as well.

Edit: Link removed, now outdated.

[Xor]

How to verify if MT is enabled?

On Os WinServer2012 X64 i have intalled dll on "syswow64" with last Megui_2513, on cpu 6/12 core (E5-1650) but rendering/encoding time appears the same as single core cpu.

[LigH]

Simply exchanging the DLL does not magically use more threads. You will have to set up multithreading manually by using SetMTMode in the script (MeGUI won't do that for you) because multithreading filters in AviSynth is not really trivial, different filters require different modes or may corrupt the video, even crash; this function will not be available if you did not exchange the DLL correctly.

You can check if an MT mode was set using GetMTMode. It will return different integer values depending on its bool parameter 'threads':

current_mode = GetMTMode(false)
num_threads = GetMTMode(true)
debug_text = "Current MT mode = "+String(current_mode)+" using "+String(num_threads)+" threads"
BlankClip().Subtitle(debug_text)


When no MT mode was initialized using SetMTMode(), I get a current mode -1 returned. If I did not have an MT version of AviSynth installed, I would instead get an error that this function is not defined.

[LigH]

Dear SEt.

Now that there is AVS 2.6.0 RC 1 [150114] (https://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20RC%201%20%5B150114%5D/), I hope there will also be an MT DLL available again...

[SEt]

It will be, but a bit later.

[LigH]

:thanks: in advance...

[Ajvar]

Yes, will keep refreshing this page once a day;)

[SEt]

Updated to current CVS. Also updated build environment to VS2013.

Note: It would be much easier to build these if at least non-MT changes would be merged upstream but no one cares, sigh...

[Boulder]

Thanks as always!

[Groucho2004]

Thanks for the new build.

Also updated build environment to VS2013.
However, that makes it incompatible with WinXP. I think there is a compatibility option for XP.

Or is the drop of XP intended?

[LigH]

http://cosgan.de/images/smilie/froehlich/e035.gif (http://www.cosgan.de/smilie.php) Hooray!

[SEt]

Have I said anywhere that XP is dropped? Then it's still supported.

[Groucho2004]

Have I said anywhere that XP is dropped? Then it's still supported.
See here (http://stackoverflow.com/questions/19724029/windows-xp-and-windows-server-2003-support-in-visual-studio-2013). Your new DLL does not work on XP.

[Taurus]

Thanks SEt for the build :thanks:

I can confirm the MT version is not working on WinXP 32bit.
The "normal" version 2.6.0 RC1 is doing fine.
The 2013 redist is installed (verified)
I dont care too much caus I'm normally working on Win7 Pro 64bit or Win 8.1.
But for compatibility reasons we should have a look on this.

[SEt]

Redownload – I've tweaked compilation a bit, should be ok now.

My builds never require any redists, so you don't need to worry about them.

[Groucho2004]

Redownload – I've tweaked compilation a bit, should be ok now.
Works now on XP, thank you.

[LigH]

Is there any additional change to log, apart from the AviSynth development?

[l33tmeatwad]

Standalone installer for the latest MT build.

Download (https://www.mediafire.com/?kofmx4apcw0qccz)
(NSIS Script (https://mega.co.nz/#!aRlwRYJa!DWb0U6b72lhQm5Uq1g1Gp0nFXSHiBhJ0VH6wE2RauTE))

Note: I changed the "Play" option to open in MPC-HC and I fixed the problem where in windows 8 it won't properly display the icon in Add/Remove programs on x64 systems because of how it writes to the registry. It includes AVSTP in the installer as well.

[SEt]

Is there any additional change to log, apart from the AviSynth development?
Just current CVS + MT + the same old my minor patches.

Standalone installer for the latest MT build.
You can safely drop msvcp60.dll from there – it shouldn't be used by anything.

[Overdrive80]

Thanks, Sir.

[l33tmeatwad]

You can safely drop msvcp60.dll from there – it should not used by anything.Thanks for the tip, updated the installer.

[Sparktank]

:thanks: Liking 2015 already.

Thanks for all the hard work guys. :)

[GMJCZP]

Thank you SEt and l33tmeatwad, working in WXP!

[Ajvar]

Thank you SEt! Will gonna use it now!;)

[GillesH]

Hello Set
And a great thank you for this great work.
Just a question :
What are the changes from the previous version.
Is it the same as version 2.6 RC1 with MT more ?
thank you

[LigH]

@ GillesH:

Already asked:

Just current CVS + MT + the same old my minor patches.

More or less all changes are in the base project of AviSynth.

[bilditup1]

Hmm, avs development not dead then? Good news...
(and thanks SeT!)

[Pat357]

Since I updated my Avisynth.dll from an older 2.6.0.3 MT version to the newest one (2015-01-25), I get an error when I use Seesaw :
AVSMeter 1.9.4.0 (x86) by Groucho2004
AviSynth 2.60, build:Jan 25 2015 [17:03:53] (2.6.0.5) (MT)

Script error: Invalid arguments to function "sharpen2"
(k:\programs\AviSynth 2.5\special filters\SeeSaw_2006.01.02\SeeSaw_.avs, line 74)
(K:\film\Safe-House-2012\Safe_10a.avs, line 43)

Line 43 in my script is the actual call for "SeeSaw (a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5, Spower=4, Sdamplo=5, Szp=16, bias=40)"
Line 74 in the SeeSaw_.avsi points the arguments of a function sharpen2(). See attachment for this SeeSaw_.avsi (txt format) or here http://avisynth.nl/images/SeeSaw.avs

Output from FFmpeg :
[avisynth @ 02920280] Script error: Invalid arguments to function "sharpen2"
(k:\programs\AviSynth 2.5\special filters\SeeSaw_2006.01.02\SeeSaw_.avs, line 74)
(\Safe_10a.avs, line 43)
\Safe_10a.avs: Unknown error occurred

About SeeSaw and download the Seesaw.avsi script : http://avisynth.nl/index.php/SeeSaw
Download Seesaw.avsi : http://avisynth.nl/images/SeeSaw.avs

My script looks like this :

......
LoadPlugin("...\plugins\RemoveGrainSSE2.dll")
LoadPlugin("...\plugins\RepairSSE2.dll")
LoadPlugin(...\plugins\RSharpenSSE2.dll")
LoadPlugin("...\Vaguedenoiser0351\VagueDenoiser.dll")
Loadplugin("..\degrainmedian_20061008\degrainmedian.dll")
LoadPlugin("path...\mt_masktools-26.dll")
Import("path .....\SeeSaw_2006.01.02\SeeSaw_.avsi")

FFmpegSource2("Safe.mkv",vtrack=-1,atrack=-1, fpsnum=24000, fpsden=1001, width=720, height=304, colorspace="YV12", threads=1)
a = last
b=a.degrainmedian(mode=2).VagueDenoiser(threshold=0.9, method=1, nsteps=6, chromaT=0.9)
SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5, Spower=4, Sdamplo=5, Szp=16, bias=40)
## SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5)

The error seems to point to a function ""sharpen2" inside the "Seesaw.avsi" .

If I use less parameters for SeeSaw by replacing the line :
SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5, Spower=4, Sdamplo=5, Szp=16, bias=40)
by this
SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5)
the script works and produces nice output.

Attached is the "SeeSaw.avsi" SeeSaw v0.3e (02 Jan 2006) as txt file.

Any idea why the newer Avisynth MT versions give an error, while the previous older 2.6.0.3 that I 've used did not ?
Is this a problem with the parameters itself or maybe with the Seesaw script ?

[SEt]

Does official version http://forum.doom9.org/showthread.php?t=171668 work or produce the same error? If error is still present - it's non-MT issue and should be reported to the official thread.

[mawen1250]

Try this one
SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5, Spower=4., Sdamplo=5., Szp=16., bias=40.)
From what I know, when specify an int to a float argument for AviSynth function, the argument will become an int variable, and when this int variable is passed to a function argument that is of float type, the error occurs.
I remember from one version on, 2.6 MT has fixed this problem (maybe 2012.08.28), also I tried this condition on AviSynth+ and it has fixed it.
Maybe the new 2.6 MT doesn't include this fix?

[StainlessS]

From Official v2.6 RC-1 ChangeList
Force int call arguments to user script function float params to be explicit floats.

[Ajvar]

Does official version work or produce the same error? If error is still present - it's non-MT issue and should be reported to the official thread.

I've never thought that it's OK to ask about errors with script but IF it is... please help.
I have a script which is working fine with Avisynth 2.6 in ST mode only while in Avisynth 2.5 it works fine in ST and MT.
Whenever I set MT mode (SetMemoryMax(1024) SetMTMode(3, 3), souce, SetMTMode(2)) it shows me a white alpha text on the video "I don't know what "fix_clip" means ([ScriptClip], line 2)".
I understand that you may not understand the script itself but I have a feeling that problem is in general rules of scripting.

I assume that it is because there is nothing before that ScriptClip("...
Import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\AudioFunctions.avs")
Import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\VideoFunctions.avs")

SetMemoryMax(1024)
SetMTMode(3, 3)

DirectShowSource("E:\Documents\Desktop\EXAMPLE.mp4", fps=25.000, convertfps=true)

SetMTMode(2)

ConvertToYV12()

###[FILTERING]###
global svp_scheduler=true
global threads=5
global svp_cache_fwd=threads+10
LoadPlugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\svpflow1.dll")
LoadPlugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\svpflow2.dll")
LoadPlugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\MVtools2mod.dll")
LoadPlugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\masktools2.dll")

src=last
super_params_mini="{scale:{up:0},gpu:1}"
analyse_params_mini="{block:{w:8,h:8}}"
miniW = int(width/64)*32
miniW = (miniW<320) ? 320 : miniW
miniH = int(height/64)*32
miniH = (miniH<160) ? 160 : miniH
mini=BicubicResize(miniW,miniH).TemporalSoften(1, 1, 0, scenechange=1, mode=2)
super_mini=mini.SVSuper(super_params_mini)
vectors_mini=SVAnalyse(super_mini, analyse_params_mini)
vectors_Forward=SVConvert(vectors_mini, false)
HorizontalSpeed_luma=mini.MMask(vectors_Forward, kind=3).convertToRGB32().PointResize(miniW/8, miniH/8).PointResize(miniW/4, miniH/4).ConvertToYV12().mt_lut(y=2, u=128, v=128)
VerticalSpeed_luma=mini.MMask(vectors_Forward, kind=4).convertToRGB32().PointResize(miniW/8, miniH/8).PointResize(miniW/4, miniH/4).ConvertToYV12().mt_lut(y=2, u=128, v=128)

size=16
luma_lft=HorizontalSpeed_luma.crop(0,0,miniW/16,0).BicubicResize(size,size)
luma_rgh=HorizontalSpeed_luma.crop(miniW/16+miniW/8,0,0,0).BicubicResize(size,size)
luma_top=VerticalSpeed_luma.crop(0,0,0,miniH/16).BicubicResize(size,size)
luma_btm=VerticalSpeed_luma.crop(0,miniH/16+miniH/8,0,0).BicubicResize(size,size)
luma_drop=luma_lft.mt_lut(y=-1, u=128, v=128)

move_idx=5
y_idx=3
min_move=0.2
max_stop=0.5
drop_clip=luma_drop.ScriptClip("
AvgLuma_lft=128-luma_lft.AverageLuma
AvgLuma_rgh=128-luma_rgh.AverageLuma
AvgLuma_lft_prev=128-(luma_lft.trim(1,1)+luma_lft).AverageLuma
AvgLuma_rgh_prev=128-(luma_rgh.trim(1,1)+luma_rgh).AverageLuma
AvgLuma_lft_next=128-luma_lft.trim(1,0).AverageLuma
AvgLuma_rgh_next=128-luma_rgh.trim(1,0).AverageLuma

AvgLuma_top=128-luma_top.AverageLuma
AvgLuma_btm=128-luma_btm.AverageLuma
AvgLuma_top_prev=128-(luma_top.trim(1,1)+luma_top).AverageLuma
AvgLuma_btm_prev=128-(luma_btm.trim(1,1)+luma_btm).AverageLuma
AvgLuma_top_next=128-luma_top.trim(1,0).AverageLuma
AvgLuma_btm_next=128-luma_btm.trim(1,0).AverageLuma

Max_lft=max(abs(AvgLuma_lft_prev),abs(AvgLuma_lft),abs(AvgLuma_lft_next))
Max_rgh=max(abs(AvgLuma_rgh_prev),abs(AvgLuma_rgh),abs(AvgLuma_rgh_next))
Max_top=max(abs(AvgLuma_top_prev),abs(AvgLuma_top),abs(AvgLuma_top_next))
Max_btm=max(abs(AvgLuma_btm_prev),abs(AvgLuma_btm),abs(AvgLuma_btm_next))
Max_all=max(Max_lft,Max_rgh,Max_top,Max_btm)

MaxLuma=max(abs(AvgLuma_lft),abs(AvgLuma_rgh),abs(AvgLuma_top),abs(AvgLuma_btm))
MaxLuma_prev=max(abs(AvgLuma_lft_prev),abs(AvgLuma_rgh_prev),abs(AvgLuma_top_prev),abs(AvgLuma_btm_prev))
MaxLuma_next=max(abs(AvgLuma_lft_next),abs(AvgLuma_rgh_next),abs(AvgLuma_top_next),abs(AvgLuma_btm_next))
dif=mini.YDifferenceFromPrevious
dif_next=mini.trim(1,0).YDifferenceFromPrevious
dif_prev=(mini.trim(1,1)+mini).YDifferenceFromPrevious

GoodContrast = (max(mini.YPlaneMinMaxDifference,mini.trim(1,0).YPlaneMinMaxDifference)>20) ? 1 : 0

drop = (MaxLuma<0.1 && MaxLuma*2<Max(MaxLuma_prev,MaxLuma_next) && dif*y_idx<max(dif_prev,dif_next)) ? 1 : 0

drop_lft = (AvgLuma_lft_prev*AvgLuma_lft_next>0 && abs(AvgLuma_lft*move_idx)<Max_lft && abs(AvgLuma_lft)<=min_move && dif*y_idx<max(dif_prev,dif_next)) ? 2 : 0
drop_rgh = (AvgLuma_rgh_prev*AvgLuma_rgh_next>0 && abs(AvgLuma_rgh*move_idx)<Max_rgh && abs(AvgLuma_rgh)<=min_move && dif*y_idx<max(dif_prev,dif_next)) ? 3 : 0
drop_top = (AvgLuma_top_prev*AvgLuma_top_next>0 && abs(AvgLuma_top*move_idx)<Max_top && abs(AvgLuma_top)<=min_move && dif*y_idx<max(dif_prev,dif_next)) ? 4 : 0
drop_btm = (AvgLuma_btm_prev*AvgLuma_btm_next>0 && abs(AvgLuma_btm*move_idx)<Max_btm && abs(AvgLuma_btm)<=min_move && dif*y_idx<max(dif_prev,dif_next)) ? 5 : 0

drop = (drop==0 && MaxLuma<Max_stop && Max_lft==Max_all) ? drop_lft : drop
drop = (drop==0 && MaxLuma<Max_stop && Max_rgh==Max_all) ? drop_rgh : drop
drop = (drop==0 && MaxLuma<Max_stop && Max_top==Max_all) ? drop_top : drop
drop = (drop==0 && MaxLuma<Max_stop && Max_btm==Max_all) ? drop_btm : drop
drop_dif = (dif<0.4 && MaxLuma<min_move) ? 6 : 0
drop = (drop==0 && drop_dif>0) ? drop_dif : drop
drop = (drop>0 && Max_all<0.2) ? 0 : drop
drop = (drop>0 && GoodContrast==0) ? 0 : drop

luma=mini.AverageLuma
luma_next=mini.trim(1,0).AverageLuma
max_luma=max(luma,luma_next)

drop = (drop>0 && max_luma<16.5) ? 0 : drop

(drop>0) ? luma_drop : \
(Max_lft==Max_all) ? luma_lft : \
(Max_rgh==Max_all) ? luma_rgh : \
(Max_top==Max_all) ? luma_top : luma_btm
")

fix_r50=luma_lft.mt_lut(y=-1, u=128, v=128)
fix_lr33=luma_lft.mt_lut(y=-2, u=128, v=128)
fix_l50=luma_lft.mt_lut(y=-3, u=128, v=128)
fix_r133=luma_lft.mt_lut(y=-4, u=128, v=128)
fix_r66=luma_lft.mt_lut(y=-5, u=128, v=128)

AvgDrop=127
MaxMulty=10
dblMulti=1.3
fix_clip=luma_drop.ScriptClip("
drop=drop_clip.AverageLuma
AvgLuma=abs(128-drop_clip.AverageLuma)
AvgLuma_prev=abs(128-(drop_clip.trim(1,1)+drop_clip).AverageLuma)
AvgLuma_prev_= (AvgLuma_prev==AvgDrop) ? 0 : AvgLuma_prev
AvgLuma_prev2=abs(128-(drop_clip.trim(1,2)+drop_clip).AverageLuma)
AvgLuma_next=abs(128-drop_clip.trim(1,0).AverageLuma)
AvgLuma_next_= (AvgLuma_next==AvgDrop) ? 0 : AvgLuma_next
AvgLuma_next2=abs(128-drop_clip.trim(2,0).AverageLuma)

RightZero = (AvgLuma_prev_*MaxMulty<AvgLuma_next_) ? (AvgLuma_prev_>max_stop || AvgLuma_next_>max_stop) ? 1 : 0 : 0
LeftZero = (AvgLuma_next_*MaxMulty<AvgLuma_prev_) ? (AvgLuma_prev_>max_stop || AvgLuma_next_>max_stop) ? 1 : 0 : 0

drop = (AvgLuma==AvgDrop && AvgLuma_next==AvgDrop) ? -50 : 0
drop = (AvgLuma==AvgDrop && AvgLuma_prev==AvgDrop) ? 50 : drop

drop = (drop==0 && AvgLuma==AvgDrop && LeftZero==0 && RightZero==0) ? \
AvgLuma_prev_>AvgLuma_next_*dblMulti ? -50 : \
AvgLuma_prev_*dblMulti>=AvgLuma_next_ ? AvgLuma_next2==AvgDrop ? 50 : 33 : 50 : drop

drop = (drop==0 && AvgLuma==AvgDrop && RightZero==0 && AvgLuma_next2==AvgDrop) ? -50 : drop
drop = (drop==0 && AvgLuma==AvgDrop && LeftZero==0 && AvgLuma_prev2==AvgDrop) ? 66 : drop

(drop==50) ? fix_r50 : \
(drop==33) ? fix_lr33 : \
(drop==-50) ? fix_l50 : \
(drop==133) ? fix_r133 : \
(drop==66) ? fix_r66 : drop_clip
")

r50=1
lr33=2
l50=3
r133=4
r66=5

super_params="{scale:{up:0},gpu:1}"
analyse_params="{main:{search:{coarse:{distance:4,bad:{sad:2000}},type:2,distance:4},penalty:{lambda:1,pglobal:10000}},refine:[{thsad:65000}]}"
smoothfps_params="{rate:{num:12,den:1},algo:13,scene:{blend:true}}"

super=SVSuper(super_params)
vectors=SVAnalyse(super, analyse_params)
fix_all = SVSmoothFps(super, vectors, smoothfps_params, mt=threads, url="www.svp-team.com")
fix50 = fix_all.SelectEvery(12,6).Subtitle("fix50", align=3, size=120)
fix33 = fix_all.SelectEvery(12,4).Subtitle("fix33", align=3, size=120)
fix66 = fix_all.SelectEvery(12,8).Subtitle("-fix33", align=3, size=120)
fix66p = fix_all.SelectEvery(12,8).Subtitle("fix66", align=3, size=120)
fix75 = fix_all.SelectEvery(12,9).Subtitle("-fix25", align=3, size=120)
fix50n = fix_all.SelectEvery(12,6).Subtitle("-fix50", align=3, size=120)
fix133 = fix_all.SelectEvery(12,4).Subtitle("fix133", align=3, size=120)
fix125 = fix_all.SelectEvery(12,3).Subtitle("fix125", align=3, size=120)

ScriptClip("
AvgFix=fix_clip.AverageLuma
AvgFix_next=fix_clip.trim(1,0).AverageLuma
AvgFix_next2=fix_clip.trim(2,0).AverageLuma
AvgFix_next3=fix_clip.trim(3,0).AverageLuma
AvgFix_prev=(fix_clip.trim(1,1)+fix_clip).AverageLuma

(AvgFix==r50) \
? (AvgFix_next2==lr33 || AvgFix_next2==l50) ? fix33 : fix50 : \
(AvgFix==lr33) ? fix33 : \
(AvgFix_next==lr33) \
? (AvgFix_prev==r66) ? fix75.trim(1,1)+fix75 : fix66.trim(1,1)+fix66 : \
(AvgFix_next==l50) \
? (AvgFix_prev==lr33 || AvgFix_prev==r50) ? fix66.trim(1,1)+fix66 \
: (AvgFix_prev==r66) ? fix75.trim(1,1)+fix75 : fix50n.trim(1,1)+fix50n : \
(AvgFix==r66) \
? (AvgFix_next2==lr33 || AvgFix_next2==l50) ? fix50 : fix66p : \
(AvgFix_next==r66) \
? (AvgFix_next3==lr33 || AvgFix_next3==l50) ? fix125.trim(1,0) : fix133.trim(1,0) : \
last
")

trim(0,framecount-10)
###[FILTERING]###

Thank you if you look at it.

[StainlessS]

This is the problem line in final scriptclip that results in error message

ScriptClip("
AvgFix=fix_clip.AverageLuma


Can you add this in blue after fix_clip.Scriptclip EDIT: Actually after fix_clip=luma_drop.ScriptClip("

#return luma_drop # EDIT: And also try with this line uncommented
fix_clip=luma_drop.ScriptClip("
drop=drop_clip.AverageLuma
AvgLuma=abs(128-drop_clip.AverageLuma)
AvgLuma_prev=abs(128-(drop_clip.trim(1,1)+drop_clip).AverageLuma)
AvgLuma_prev_= (AvgLuma_prev==AvgDrop) ? 0 : AvgLuma_prev
AvgLuma_prev2=abs(128-(drop_clip.trim(1,2)+drop_clip).AverageLuma)
AvgLuma_next=abs(128-drop_clip.trim(1,0).AverageLuma)
AvgLuma_next_= (AvgLuma_next==AvgDrop) ? 0 : AvgLuma_next
AvgLuma_next2=abs(128-drop_clip.trim(2,0).AverageLuma)

RightZero = (AvgLuma_prev_*MaxMulty<AvgLuma_next_) ? (AvgLuma_prev_>max_stop || AvgLuma_next_>max_stop) ? 1 : 0 : 0
LeftZero = (AvgLuma_next_*MaxMulty<AvgLuma_prev_) ? (AvgLuma_prev_>max_stop || AvgLuma_next_>max_stop) ? 1 : 0 : 0

drop = (AvgLuma==AvgDrop && AvgLuma_next==AvgDrop) ? -50 : 0
drop = (AvgLuma==AvgDrop && AvgLuma_prev==AvgDrop) ? 50 : drop

drop = (drop==0 && AvgLuma==AvgDrop && LeftZero==0 && RightZero==0) ? \
AvgLuma_prev_>AvgLuma_next_*dblMulti ? -50 : \
AvgLuma_prev_*dblMulti>=AvgLuma_next_ ? AvgLuma_next2==AvgDrop ? 50 : 33 : 50 : drop

drop = (drop==0 && AvgLuma==AvgDrop && RightZero==0 && AvgLuma_next2==AvgDrop) ? -50 : drop
drop = (drop==0 && AvgLuma==AvgDrop && LeftZero==0 && AvgLuma_prev2==AvgDrop) ? 66 : drop

(drop==50) ? fix_r50 : \
(drop==33) ? fix_lr33 : \
(drop==-50) ? fix_l50 : \
(drop==133) ? fix_r133 : \
(drop==66) ? fix_r66 : drop_clip
")
Return fix_clip

It may get you one step closer to figuring out what the problem is, may perhaps give another cryptic message from that Scriptclip instance.

[Ajvar]

This is the problem line in final scriptclip that results in error message

It may get you one step closer to figuring out what the problem is, may perhaps give another cryptic message from that Scriptclip instance.

The problem is that everything from the last ScriptClip is the problem. Just out of curiosity I put luma_drop instead of fix_clip and result is it doesn't know what's luma_drop.

The only difference with last ScriptClip is that there is nothing before it like XXX=YYY.Scriptclip. And this error comes only when I turn on MT. MT version of 2.6 doesn't like ScripClips without header?

With return fix_clip all gets blurred and with return luma_drop all is black. But thanks for trying.

[StainlessS]

The problem is that everything from the last ScriptClip is the problem. Just out of curiosity I put luma_drop instead of fix_clip and result is it doesn't know what's luma_drop.

Nope, the problem is before that as your Luma_drop (and my suggested edit) shows.


With return fix_clip all gets blurred and with return luma_drop all is black.

Yep, the point was to try to ascertain (or get nearer to) the cause of the problem, not to make your script work.
I'll leave it to you.

[Pat357]

Try this one
SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5, Spower=4., Sdamplo=5., Szp=16., bias=40.)
From what I know, when specify an int to a float argument for AviSynth function, the argument will become an int variable, and when this int variable is passed to a function argument that is of float type, the error occurs.
I remember from one version on, 2.6 MT has fixed this problem (maybe 2012.08.28), also I tried this condition on AviSynth+ and it has fixed it.
Maybe the new 2.6 MT doesn't include this fix?

Thanks, I've tested this, but no avail :
SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5, Spower=4., Sdamplo=5., Szp=16., bias=40.)
still gives the same error.

However, just omitting the Spower=4 like this :
SeeSaw(a,b, NRlimit=3, NRlimit2=4, Sstr=1.5, Slimit=5 , Sdamplo=5, Szp=16, bias=40)
is just fine.
It looks like this Spower parameter causes the problem
Spower=4. or Spower=4 or Spower=4.0 all give the same error.

It seems like float versus ints is not the problem..
Any other ideas ?

[Pat357]

I've Seesaw working now with the official latest non MT 2.6.0.5 version (2.6_RC1).
Here's what I did : in the Seesaw.avsi, I replaced the parameter "power" from type ""int" to "float" (line 95, "function Sharpen2()" ).

The script now properly works with Avisynth 2.6 RC1.

After this I retested the latest MT version, and got an error.
I didn't use any SetMTMode() in the script.

The error I have now is :
AVSMeter 1.9.4.0 (x86) by Groucho2004
AviSynth 2.60, build:Jan 25 2015 [17:03:53] (2.6.0.5) (MT)

Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 2697464
(k:\programs\AviSynth 2.5\special filters\SeeSaw_2006.01.02\SeeSaw_.avs, line 72)
(K:\film\Safe_10a.avs, line 42)
Line 72 from the Seesaw.avsi looks like :
NRdiff = mt_makediff(clp,denoised,chroma="process")

Is this an MT related error ?

[SEt]

Pat357, the buggy script is obviously at fault for first error:

function SeeSaw(..., float "Spower", ...) # here Spower is declared as float and passed values would be treated as floats
{
...
Spower = default( Spower, 4 ) # and here if Spower is not defined it will be re-assigned value 4, so it'll become int
...
sharpen2(Sstr,Spower,Szp,SdampLo,SdampHi,Smode) # faulting call
}
function sharpen2(clip clp, float strength, int power, float zp, float lodmp, float hidmp, int rgmode)
{
PWR = string( 1.0/float(power) ) # awful writing: parameter power is declared as int, but used only as float -> should replace declaration to float and remove conversion here
}


The second your error
AVSMeter 1.9.4.0 (x86) by Groucho2004
AviSynth 2.60, build:Jan 25 2015 [17:03:53] (2.6.0.5) (MT)

Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 2697464
(k:\programs\AviSynth 2.5\special filters\SeeSaw_2006.01.02\SeeSaw_.avs, line 72)
(K:\film\Safe_10a.avs, line 42)
Line 72 from the Seesaw.avsi looks like :
NRdiff = mt_makediff(clp,denoised,chroma="process")
looks like you are using wrong version of masktools2.dll. You should use (any version 2.5) or (2.6 build exactly for this Avisynth interface version).

[kuchikirukia]

I get the error:

nnedi3: arg 0 must be a clip!
(QTGMC-3.32.avsi, line 721)
(QTGMC-3.32.avsi, line 510)

When i use Avisynth 2.6 later then 2012.05.16 i think.

Tried searching on it, but i can´t find anyone else who got it, atleast not in english.

Crap, same error, using nothing but presets using a script that's worked before. I wonder if it's the MBAFF interlacing of the source?

E got it working. Used all the dll's in the "Plugin Package for multithreading" package on the wiki, which then threw a different error, tracked down to mt_masktools-26.dll. Changed to a different version and it's up.
Now I wonder if there's any hope of getting this working multithreaded...

e2: I figured out the nnedi3 bug. The 0.9.4.0 version on the nnedi3 wiki is not the 0.9.4.0 in the qtgmc wiki plugins download. If you use the one on the nnedi3 wiki (13,746,176 bytes) (Sunday, April 01, 2012, 6:30:50 PM) you get the error. Use the one in the QTGMC package (13,737,984 bytes) (Friday, September 09, 2011, 12:54:34 PM) and it's fine.

[VideoFanatic]

What are the new features/bug fixes of Avisynth 2.6 MT 2015.01.25 compared to 2013.09.28?

[Xebika]

What are the new features/bug fixes of Avisynth 2.6 MT 2015.01.25 compared to 2013.09.28?

You got your answer here: http://forum.doom9.org/showpost.php?p=1707122&postcount=910

[VideoFanatic]

You got your answer here: http://forum.doom9.org/showpost.php?p=1707122&postcount=910

I don't see any changes mentioned there.

[Groucho2004]

I don't see any changes mentioned there.
I suppose this (http://forum.doom9.org/showthread.php?t=171668) is what you're looking for.

[VideoFanatic]

I suppose this (http://forum.doom9.org/showthread.php?t=171668) is what you're looking for.

That's Avisynth changes. I'm looking for Avisynth MT changes.

[StainlessS]

Groucho already gave you changes, MT v2.6 is MT version of v2.6, what is so difficult to grasp ?

[VideoFanatic]

Groucho already gave you changes, MT v2.6 is MT version of v2.6, what is so difficult to grasp ?

I realise the changes of Avisynth also apply to MT but I want to know what specific MT changes there have been.

[Groucho2004]

I want to know what specific MT changes there have been.

------->

I don't see any changes mentioned there.

:rolleyes:

[VideoFanatic]

I don't get the joke. Where are the MT specific changes mentioned?

[StainlessS]

http://forum.doom9.org/showthread.php?p=1707122#post1707122

[Groucho2004]

I don't get the joke. Where are the MT specific changes mentioned?
There are no MT specific changes. Ligh asked the same question. SEt's answer clearly indicates that there are no MT specific changes. There is nothing ambiguous about it.

[LigH]

Or in different words:

The difference between AviSynth 2.60 alpha 4 and AviSynth MT 2.60 alpha 4 is about the same as the difference between AviSynth 2.60 RC1 and AviSynth MT 2.60 RC1.

I remember only one specific difference between alpha 3 and alpha 4 regarding the interface and caching modes, which made some elaborate plugins like MaskTools crash and required a new set of DLLs compatible to MT alpha 4 and newer. But nothing similar since which I would be aware of.

[Ghostlamer]

SEt, looks like in your latest version (2015.01.25) assumefps partially broken, when i change the frame rate (with sound) using the assumefps, the sound is distorted, begins to crack ...
In original non-mt version (Jan 14th, 2015), all fine.

[SEt]

I can't reproduce it. Can you provide a sample and script?

[Ghostlamer]

Of course, here : http://www.mediafire.com/download/2p55hqfnreo869b/sample.zip

[SEt]

Indeed some part of audio was built broken. See the updated version.

[tobindac]

Wow. This appears to have fixed hangs I've been having with SVP when seeking. Great thanks.

PS. It's probably about the fixes and not the mt support per se since the version I had had mt commands already.

thread in svp's forum: http://www.svp-team.com/forum/viewtopic.php?pid=46950#p46950

[Ajvar]

Wow. This appears to have fixed hangs I've been having with SVP when seeking. Great thanks.

PS. It's probably about the fixes and not the mt support per se since the version I had had mt commands already.

thread in svp's forum: http://www.svp-team.com/forum/viewtopic.php?pid=46950#p46950

I believe it has nothing to do with this if you use old 2.5 Avisynth which comes with SVP.

[Boulder]

Lately I've been getting weird crashes pointing to kernelbase.dll in VirtualDub. They appear when for example seeking forward, then backwards beyond the initial starting point, or when using F2 to reload the script. If I close the script and open it, the crash does not occur.

I asked about this issue at the VDub support forum but apparently the problem is Avisynth-related. In the seeking case, the reason for the crash is "Unhandled Microsoft C++ exception" and with F2 it's "A privileged instruction or unaligned SSE/SSE2 access occurred in module 'VirtualDub'." I can get you the crashinfo.txt files if needed. The crash can be reproduced with just MPEG2Source or DGSource in the script.

Can anyone point me to the right direction in what to try next? I have tried reverting back to the Sept 2013 Avisynth MT build but it also shows this issue.

[Groucho2004]

Lately I've been getting weird crashes pointing to kernelbase.dll in VirtualDub. They appear when for example seeking forward, then backwards beyond the initial starting point, or when using F2 to reload the script. If I close the script and open it, the crash does not occur.

I asked about this issue at the VDub support forum but apparently the problem is Avisynth-related. In the seeking case, the reason for the crash is "Unhandled Microsoft C++ exception" and with F2 it's "A privileged instruction or unaligned SSE/SSE2 access occurred in module 'VirtualDub'." I can get you the crashinfo.txt files if needed. The crash can be reproduced with just MPEG2Source or DGSource in the script.

Can anyone point me to the right direction in what to try next? I have tried reverting back to the Sept 2013 Avisynth MT build but it also shows this issue.
The first thing to check is obviously if the same happens with the "official" Avisynth.
Secondly, does it happen when you remove SetMTMode statements from the script?

[Boulder]

Yes, the same thing occurs with the official Avisynth :( The weird thing is that this is not an old issue, I'd say it's been like this for some months now.

[chainik_svp]

Indeed some part of audio was built broken. See the updated version.

so, what was that? :) diff.7z is unchanged

[Groucho2004]

Yes, the same thing occurs with the official Avisynth :( The weird thing is that this is not an old issue, I'd say it's been like this for some months now.
More thoughts -
Does it happen with every script?
Maybe a plugin mis-behaving?
Have you tried AVSPMod instead of VDub?

[foxyshadis]

I'd clear the autoload plugins folder first. I bet it's a misbehaving plugin scribbling over memory it shouldn't.

[LigH]

There is an ongoing discussion about issues with QTGMC filtering video from an uncompressed YUY2-in-AVI video. Depending on the number of threads, reproducably a different frame is messed up, e.g. skewed (horizontally shifted and wrapped around) by about a third of the width (like the frame data was read with an offset), or completely exchanged by the content of a frame about 20 frames off.

I wonder if this may be related to competitive frame requests. Neither MT mode 3 nor 5 for AviSource seem to make a difference. What would you recommend to try? Should a rather large Preroll help to avoid it?

No more details here yet, the discussion in the german forum is still a bit nested...

[Boulder]

@foxyshadis: Thanks, I'll try that first as soon as my current encode finishes.

@LigH: All the problems I've had with "weird behaviour" have been solved with PreRoll so it's definitely something to test. My DGSource issues disappeared after using PreRoll(video=25), smaller values were sometimes not enough.

[LigH]

Thank you; apparently, the frame mess happens in VirtualDub previews but not during a conversion with x264 ... more to investigate ... I don't have that material, only reading reports from another user. We are probably on an interesting track. AviSynth MT may not be the only participant to blame.

[SEt]

In the seeking case, the reason for the crash is "Unhandled Microsoft C++ exception" and with F2 it's "A privileged instruction or unaligned SSE/SSE2 access occurred in module 'VirtualDub'." I can get you the crashinfo.txt files if needed. The crash can be reproduced with just MPEG2Source or DGSource in the script.
You should post crash logs and the most of other information you can provide – way better chances that someone would be able to figure out the issue.

so, what was that? :) diff.7z is unchanged
Like I said, "was built broken" – there were issues with my compiler tweaks when moved to VS2013.

[chainik_svp]

Like I said, "was built broken" – there were issues with my compiler tweaks when moved to VS2013.

and if someone'd like to build it on his own he should pay attention to ... what? :)

[tobindac]

I believe it has nothing to do with this if you use old 2.5 Avisynth which comes with SVP.

SVP was hanging with a 2.5 mt build. This latest 2015 build fixed it.

[SEt]

and if someone'd like to build it on his own he should pay attention to ... what? :)
Uhm... nothing? If you don't want to link with msvcrt.dll instead of standard runtime like I do.

[Boulder]

I'd clear the autoload plugins folder first. I bet it's a misbehaving plugin scribbling over memory it shouldn't.I think I nailed it, cleared the folder and then added all the necessary plugins one-by-one until all my regular stuff works. Let's hope the issue won't reappear any time soon, not having the quick reload in VDub can be a real pain..

Thanks again to everyone!

[speedyrazor]

Hi, I would like to enquire if this version of MT has the latest SoundTouch library included, as Wilber informed me over in this thread, http://forum.doom9.org/showthread.php?p=1711591#post1711591, about a year ago they fixed SoundTouch to be multichannel aware, which I need.
So just wondered if MT includes this?

Kind regards.

[LigH]

If the normal AviSynth variant of the same version includes it, then the MT variant includes it too.

[bxyhxyh]

Hi, I'm using two sources, is it correct to call SetMTMode(3,2) this way?

SetMTMode(3,2)
source1=lwlibavvideosource("D:\EFG\BDMV\Stream\00000.m2ts")
SetMTMode(3,2)
source2=lwlibavvideosource("00000.m2ts")

SetMTMode(2)
source1.ConvertToY8()
crop(1,0,-1,0)
t=last
mt_lut("x 128 > x 1.1 * x 1.25 * ?")
Overlay(t.crop(1,0,-1,0),1)
addborders(1,0,1,0)
Overlay(last,source2.converttoy8().crop(3,0,-3,0),3)
ConvertToYV12().mergechroma(source2)

[Boulder]

You don't need the second SetMTMode(3,2) line, the first one is already applied.

[l33tmeatwad]

Updated full installer (http://www.mediafire.com/download/kofmx4apcw0qccz/AviSynthMT_2.6_RC1.exe).

[Kein]

Is there somewhere a list of known and tested plugins that have issues with MT version? 64 pages is a paint to read.

[Selur]

Is there somewhere a list of known and tested plugins that have issues with MT version?
No, but if you write one put it into a spreadsheet or something where others can access it. :)

[Xor]

Updated full installer (http://www.mediafire.com/download/kofmx4apcw0qccz/AviSynthMT_2.6_RC1.exe).

This include last MT dll (2015) directly in setup for X64 Os ?

If use Win2012 X64 just install and finish (without overwriting libraries) ?

Thanks

[l33tmeatwad]

The installer works just like the regular AviSynth installer, but it uses the latest MT dll instead of the regular AviSynth.dll

Sent from my SCH-I545 using Tapatalk

[LouieChuckyMerry]

Hello, and thanks in advance for any help. And an extra thank you for SEt :) . I'm preparing to encode my early seasons Simpsons DVD's, but I'm having trouble with AviSynth 2.6 MT. On my Windows 7 64 bit, hyperthreaded i7 3840QM, 16GB RAM, Intel HD Graphics 4000-NVIDIA NVS 5400M setup, with the absolute minimum of necessary plugins, I can successfully complete the following script:

SetMemoryMax(400)
SetMTMode(3,8)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\ffms\ffms2.dll")
FFVideoSource("D:\Temp\S1.E1-OriginalVideo[NTSC].mkv", fpsnum=30000, fpsden=1001, threads=1)
### Deinterlace ###
SetMTMode(2)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
TFM(Order=0,Slow=2,PP=0).TDecimate(Mode=1)
Vinverse()
### Deshaker ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
RatioResize(10/11.0,"PAR")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",thY1=20,thY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(dfttest(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(tr=2,thSAD=600,ContraSharp=True,RefineMotion=True,Plane=0,Lsb_Out=True,PreFilter=2)
### Debanding ###
GradFun3(thR=0.55,Radius=12,Mask=2,SMode=1,Lsb=True,Lsb_In=True, StaticNoise=True,Y=3,U=3,V=3)
DitherPost(Stacked=True,Prot=False,Mode=0)
### Line Darkener And Thinner ###
FastLineDarkenMod(Strength=20,Prot=6,Thinning=0)
aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)

However, using the exact same AviSynth 2.6 MT-MeGUI-absolute minimum necessary plugins combination on my Windows 7 64 bit, hyperthreaded i5 3320M, 8GB RAM, Intel HD Graphics 4000-NVIDIA NVS 5400M setup, every possible dual-core modification to the above script that I've tried fails eventually, some sooner than others ;) . After reading the first page and the last 29 pages of this thread I've tried:

1) SetMemoryMax from disabled to (400) in increments of 100; 100 was slower than non-MT mode, 200 failed after about 40%, 300 failed sooner, 400 failed much sooner, always the failure was relatively gradual with the fps dropping until the time remaining counter started going backwards :( .

2) I've tried the above SetMemoryMax numbers with the initial SetMTMode as SetMTMode(3,4), SetMTMode(3), SetMTMode(5,4), and SetMTMode(5); I've also tried applying SetMTMode(5) for TIVTC and SetMTMode(2) for the rest. All resulted in failure, usually the slow fade to standstill, but occasionally an "avs4x264mod.exe has stopped working" message.

3) I've tried adding Preroll(25) and Preroll(100) to the script, both failed.

I'd very much like to get this script to run in MT mode on my dual-core laptop, but my very limited knowledge has been exhausted, leading me here. Please, does anybody have any suggestions (to make the script work, ha ha)? Thanks for your time.

[Groucho2004]

1) SetMemoryMax from disabled to (400) in increments of 100; 100 was slower than non-MT mode, 200 failed after about 40%, 300 failed sooner, 400 failed much sooner, always the failure was relatively gradual with the fps dropping until the time remaining counter started going backwards :( .
Just a couple of observations/suggestions:

There is no "disabled" state for SetMemoryMax. If you don't specify it, the default is 512 (MB). Since you're piping on a 64 Bit OS, you should allocate more memory to Avisynth - 1024 for example. You have almost 4GB available exclusive for Avisynth in your scenario.

Your script is very complex, involving a large number of plugins. Try to isolate the problem by adding functions step by step. Start with TFM, then denoise, then De-Band. Don't use megui to test the script. Use AVSMeter for testing which excludes the encoding part.

[LouieChuckyMerry]

There is no "disabled" state for SetMemoryMax. If you don't specify it, the default is 512 (MB).

I didn't notice this on the first page, thanks for the information.


Since you're piping on a 64 Bit OS, you should allocate more memory to Avisynth - 1024 for example. You have almost 4GB available exclusive for Avisynth in your scenario.

Interesting. It's seemed to me that I've been running out of (using too much) memory, but perhaps I'm not allotting enough? I thought this because on my quad-core laptop "SetMemoryMax(512)" fails but "SetMemoryMax(400) succeeds. :confused:


Your script is very complex, involving a large number of plugins. Try to isolate the problem by adding functions step by step. Start with TFM, then denoise, then De-Band. Don't use megui to test the script. Use AVSMeter for testing which excludes the encoding part.

I've been using MeGUI for testing because I figure if it succeeds I've one less episode to encode :D . I checked AVSMeter out (thanks again, great tool) and understand how to use it, but I'm not sure how to interpret the results. What would I look for?

Thanks for your help, Groucho2004 :) .

[Groucho2004]

I thought this because on my quad-core laptop "SetMemoryMax(512)" fails but "SetMemoryMax(400) succeeds. :confused:
Yes, that seems odd. You'll just have to experiment with the numbers.

I checked AVSMeter out (thanks again, great tool) and understand how to use it, but I'm not sure how to interpret the results. What would I look for?
Does it slow down and/or stall as it does in megui? If so, at what point in terms of enabled plugins does that happen?

[LouieChuckyMerry]

Yes, that seems odd. You'll just have to experiment with the numbers.

I think I need to gain a better understanding of virtual memory in windows 7.


Does it slow down and/or stall as it does in megui? If so, at what point in terms of enabled plugins does that happen?

This script:

SetMemoryMax(1024)
SetMTMode(5,4)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\ffms\ffms2.dll")
FFVideoSource("D:\Temp\[0000]ReEncTemp\TheSimpsons-S1[S][Commentary]{1989-90}[480p][NTSC]\S1.E7-TheCallOfTheSimpsons[S][Commentary][480p]\S1.E7-OriginalVideo,OriginalAudios[NTSC].mkv", fpsnum=30000, fpsden=1001, threads=1)
### Deinterlace ###
SetMTMode(2)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
TFM(Order=0,Slow=2,PP=0).TDecimate(Mode=1)
# SetMTMode(2)
Vinverse()
### Deshaker ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
RatioResize(10/11.0,"PAR")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",thY1=20,thY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(dfttest(),Mask,Luma=True)
### Overall Temporal Denoise, Could Probably Be Optimized ###
#SMDegrain(tr=2,thSAD=600,ContraSharp=True,RefineMotion=True,Plane=0,Lsb_Out=True,PreFilter=2)
### Debanding ###
#GradFun3(thR=0.55,Radius=12,Mask=2,SMode=1,Lsb=True,Lsb_In=True, StaticNoise=True,Y=3,U=3,V=3)
#DitherPost(Stacked=True,Prot=False,Mode=0)
### Line Darkener And Thinner ###
#FastLineDarkenMod(Strength=20,Prot=6,Thinning=0)
#aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)


finished successfully with AVSMeter, but when I added the denoising block and tried again it eventually stalled like it's does in MeGUI (I had to kill the process so there's no log). Also, the same script (with the added noise block) but with SetMemoryMax(2048) started very fast but didn't finish. I've run so many tests that I'm becoming (more) confused.

I'm wondering if I need to reboot before every attempt so that the physical and virtual memories are both primed and ready to go, because it seems like each successive test fails sooner than the last. Of course, this could just be what's left of my mind playing tricks on me, ha ha. I need improved organization of failed scripts, maybe I'll hire a secretary ;) , one who can explain virtual memory to me...

[Groucho2004]

This script:

SetMemoryMax(1024)
SetMTMode(5,4)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\ffms\ffms2.dll")
FFVideoSource("D:\Temp\[0000]ReEncTemp\TheSimpsons-S1[S][Commentary]{1989-90}[480p][NTSC]\S1.E7-TheCallOfTheSimpsons[S][Commentary][480p]\S1.E7-OriginalVideo,OriginalAudios[NTSC].mkv", fpsnum=30000, fpsden=1001, threads=1)
### Deinterlace ###
SetMTMode(2)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
TFM(Order=0,Slow=2,PP=0).TDecimate(Mode=1)
# SetMTMode(2)
Vinverse()
### Deshaker ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
RatioResize(10/11.0,"PAR")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",thY1=20,thY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(dfttest(),Mask,Luma=True)
### Overall Temporal Denoise, Could Probably Be Optimized ###
#SMDegrain(tr=2,thSAD=600,ContraSharp=True,RefineMotion=True,Plane=0,Lsb_Out=True,PreFilter=2)
### Debanding ###
#GradFun3(thR=0.55,Radius=12,Mask=2,SMode=1,Lsb=True,Lsb_In=True, StaticNoise=True,Y=3,U=3,V=3)
#DitherPost(Stacked=True,Prot=False,Mode=0)
### Line Darkener And Thinner ###
#FastLineDarkenMod(Strength=20,Prot=6,Thinning=0)
#aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)


finished successfully with AVSMeter, but when I added the denoising block and tried again it eventually stalled like it's does in MeGUI (I had to kill the process so there's no log). Also, the same script (with the added noise block) but with SetMemoryMax(2048) started very fast but didn't finish.
I don't know SMDegrain so I suggest you address the author about the issue.


I'm wondering if I need to reboot before every attempt so that the physical and virtual memories are both primed and ready to go, because it seems like each successive test fails sooner than the last.
No need to reboot. Once the process finishes (even if killed), all memory is released.

[Ajvar]

For your kind of work you better try Xvid4PSP 5 (https://code.google.com/p/xvid4psp/). It has built-in Preview if you don't use script view so you don't need to do smth to test, it just tells you what is missing in script if smth goes wrong with it.

There is Avisynth>MT tab where you can set stuff including "Distributor".

[LouieChuckyMerry]

No need to reboot. Once the process finishes (even if killed), all memory is released.

Thanks for the confirmation, Groucho2004.


Avisynth MT can crash or deadlock if many MT Masktools plugins are in the script. I tried to play with this since 2.5.8 MT, but unsuccessfully. Probably MT Masktools has a bug.

This was in the back of my mind, thanks for dislodging it ;) . I'm currently using TurboPascal7's (http://forum.doom9.org/showthread.php?p=1655989#post1655989) MT mod of Masktools2; I'll check things out with Vit's (http://forum.doom9.org/showpost.php?p=1423459) MT mod and see if things improve.


So I separate processing to different phases to fix this issue.
Also ffms2 runs better with Avisynth MT in 1 thread. Try to change it to LSMASHVideoSource (or LWLibavVideoSource). It works better with MT in my knowledge.

This raises another question I've been meaning to ask: I use FFMS2-Mkv because that's what I happened upon when I began using AviSynth. Would there be an actual speed-stability advantage to DGIndex(NV)-VOB or, as you suggest, LSMASHWorks. Would I use LSMASHWorks with Mkvs or VOBs?

[LigH]

L-SMASH Source will support single input files better than a group of segments. You may extract a movie PGC from a DVD (with a ripper in Movie/IFO mode or PGCDemux) to a contiguous "PGC VOB", but I doubt it will read a group of max-1-GB VOBs.

[LouieChuckyMerry]

L-SMASH Source will support single input files better than a group of segments. You may extract a movie PGC from a DVD (with a ripper in Movie/IFO mode or PGCDemux) to a contiguous "PGC VOB", but I doubt it will read a group of max-1-GB VOBs.

Would you be willing to translate that, LigH ;) ? Seriously, I think I understand, but I'm not 100% sure what you mean. Each episode I'm wanting to encode is presently an Mkv file, but I could just as easily revert to the single-episode VIDEO_TS.VOB files if the results would be better. After a day of testing, indexing the Mkv's with LSMASHWorks is proving to be a much more functional option than FFMS2; AviSynth 2.6 MT has been much more stable (and a bit faster) with this method.

[LigH]

In brief: With FFMS2 or L-SMASH Source, do prefer MKVs. With DG, VOB files will work too (but you should have extracted "the main movie" from a DVD, not simply used them as they were on DVD).

[LouieChuckyMerry]

In brief: With FFMS2 or L-SMASH Source, do prefer MKVs. With DG, VOB files will work too (but you should have extracted "the main movie" from a DVD, not simply used them as they were on DVD).

I'm dealing with ~23 minute episodes, each of which is a single VOB file, so there's no issue. In your opinion, which is the best approach with AviSynth 2.6 MT: Mkv-FFMS2, Mkv-LSMASH, or VOB-DG?


LouieChuckyMerry, TurboPascal7's MT mod also has this issue. I got deadlocks yesterday. I have many masking to keep quality - so I have many threads for each filter instance - the result: many chance to get fail. I have a top Intel i7 cpu. Not sure that it is your case, but I see your script is very complex.

Where did you get this "deadlocks" mod, hey hey! Share with the rest of us, don't keep it to yourself! ;)


LSMASHVideoSource works with mp4 and mov, but has LWLibavVideoSource in the same dll. It should open any video. To use LSMASHVideoSource if really need, you can rewrap videos to mov using ffmpeg. It is fast. But some videos, i.e. from Sony NEX5 25p, still require DSS2. For speed processing, all non-compatible videos can be extracted to lossless h.264 or utcodec.

LSMASH has been working very well with my Mkv's in MeGUI, actually better than FFMS2, so that's not a problem (thanks again for the suggestion :) ). I'm just wondering, given that LSMASH is superior to FFMS2, which, in your opinion, is better with AviSynth 2.6 MT: LSMASH-Mkv or DG-VOB?


Thank you for your help.

[LouieChuckyMerry]

PS. L-SMASH Source is compatible with MT mode 2.

Is this good because it would be faster? More stable?

[Boulder]

For VOBs I definitely recommend DGMPGDec. Just use at least SetMTMode(3) before the source filter.

[LouieChuckyMerry]

For VOBs I definitely recommend DGMPGDec. Just use at least SetMTMode(3) before the source filter.

Thanks for your input, Boulder (you Animal(s) :) ). Do you think a DG-VOB combination would be a speed-stability improvement over LSMASH-Mkv?

[Boulder]

It's very stable, I don't think I've ever had it crash, and does support random seeking without any issues. If you have the cash to spare, you can buy a license of DGDecNV and utilize an NVidia GPU to decode MPEG2, VC-1 or H264 streams.

[LouieChuckyMerry]

I've an NVIDIA GPU, but is the gain worth the money, do you think, for DGDecNV?

[Boulder]

Not for MPEG2 streams, but if convert Blu-rays with VC-1 or MPEG4 AVC video, it's a good investment. In fact, it's the only thing I've used for those.

[LigH]

The issue with VOB files is not only if the clip fits in a GByte (the limit of the ISO-9660 file system). There is also an issue when the VOB does not contain the clip only, but more (e.g. pre- and post-stills or even -trailers to enable authoring trickery or annoy paying customers); not to mention advanced authoring features like Multi-Angle or Seamless Branching. Always extract one PGC with one angle so that source plugins which don't interpret IFO files on their own can handle the result.

[LouieChuckyMerry]

Not for MPEG2 streams, but if convert Blu-rays with VC-1 or MPEG4 AVC video, it's a good investment. In fact, it's the only thing I've used for those.

Thanks for that :) .


The issue with VOB files is not only if the clip fits in a GByte (the limit of the ISO-9660 file system). There is also an issue when the VOB does not contain the clip only, but more (e.g. pre- and post-stills or even -trailers to enable authoring trickery or annoy paying customers); not to mention advanced authoring features like Multi-Angle or Seamless Branching. Always extract one PGC with one angle so that source plugins which don't interpret IFO files on their own can handle the result.

Thanks for the detailed information. Luckily my NTSC DVD's are old and simple ;) .

[Seedmanc]

I wouldn't be wasting money on daiz. Just my 2c, but you're the boss.

[LigH]

Older FFMS2 will read only MKV without too many restraints. DGDec{NV|IM} should read MKV too (DGMPGDec not yet).

[LouieChuckyMerry]

With the help of the kind people here and extensive testing (special thanks to Groucho2004's AVSMeter :) ), I'm now able to run my script in AviSynth 2.6 MT with seeming stability on my dual-core and quad-core laptops (encoding directly to x264, no intermediary). Thank you all for your help! :thanks: In case someone someday finds this information useful, and seeing as how no paper is being wasted:

1) Windows 7 64 bit, hyperthreaded i5 3320M, 8GB RAM setup. The following script successfully runs multiple queued encodes in MeGUI, achieving ~2.65 FPS, a three-times improvement over normal AviSynth's ~0.85 FPS:

SetMemoryMax(256)
SetMTMode(3,3)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\Temp\S1.E1-OriginalVideo[NTSC].mkv")
SetMTMode(2)
### Deinterlace ###
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
TFM(Order=0,Slow=2,PP=0).TDecimate(Mode=1)
Vinverse()
### Deshaker ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
RatioResize(10/11.0,"PAR")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",thY1=20,thY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(dfttest(),Mask,Luma=True)
### Overall Temporal Denoise, Could Probably Be Optimized ###
SMDegrain(tr=2,thSAD=600,ContraSharp=True,RefineMotion=True,Plane=0,Lsb_Out=True,PreFilter=2)
### Debanding ###
GradFun3(thR=0.55,Radius=12,Mask=2,SMode=1,Lsb=True,Lsb_In=True, StaticNoise=True,Y=3,U=3,V=3)
DitherPost(Stacked=True,Prot=False,Mode=0)
### Line Darkener And Thinner ###
FastLineDarkenMod(Strength=20,Prot=6,Thinning=0)
aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)


2) Windows 7 64 bit, hyperthreaded i7 3840QM, 16GB RAM setup. The following script successfully runs multiple queued encodes in MeGUI, achieving ~5.1 FPS, a not-quite two-times improvement over normal AviSynth's ~2.8 FPS:

SetMemoryMax(512)
SetMTMode(3,6)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\Temp\S1.E1-OriginalVideo[NTSC].mkv")
SetMTMode(2)
### Deinterlace ###
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
TFM(Order=0,Slow=2,PP=0).TDecimate(Mode=1)
Vinverse()
### Deshaker ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
RatioResize(10/11.0,"PAR")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",thY1=20,thY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(dfttest(),Mask,Luma=True)
### Overall Temporal Denoise, Could Probably Be Optimized ###
SMDegrain(tr=2,thSAD=600,ContraSharp=True,RefineMotion=True,Plane=0,Lsb_Out=True,PreFilter=2)
### Debanding ###
GradFun3(thR=0.55,Radius=12,Mask=2,SMode=1,Lsb=True,Lsb_In=True, StaticNoise=True,Y=3,U=3,V=3)
DitherPost(Stacked=True,Prot=False,Mode=0)
### Line Darkener And Thinner ###
FastLineDarkenMod(Strength=20,Prot=6,Thinning=0)
aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)



L-SMASHWorks proved to be much more stable than FFMS2, and the final trick was to lower the number of cores by 25%. I'd reckon that these settings could be fine-tuned to squeeze a wee bit more FPS's, especially with the quad-core, but since I'm using the dual-core for these encodes it's OK. Thanks again for all the help, I really appreciate it :) . Now to figure out how to use AviSynth 2.6 MT with QTGMC on the quad-core ;) ...

[Boulder]

One thing: TDecimate should not be run multithreaded. You'll want to have SetMTMode(5) before that and switch back to SetMTMode(2) afterwards. I'm not sure if SetMTMode(3) works with TDecimate (it didn't on my computer whenever I've tried it).

[LouieChuckyMerry]

One thing: TDecimate should not be run multithreaded. You'll want to have SetMTMode(5) before that and switch back to SetMTMode(2) afterwards. I'm not sure if SetMTMode(3) works with TDecimate (it didn't on my computer whenever I've tried it).

Thanks for the reminder. As I read through the second half of this thread before posting I saw where you'd mentioned that earlier, and as I ran my tests it's something I tried. It failed, but that was before I lowered the number of threads. I'll try again with the stable settings, but I've already encoded over 20 episodes and not noticed anything wrong with the quality. Really, they look great :confused: .

Edit: I ran two SelectRangeEvery(1000,66)'s on the same episode, one as above and one with SetMTMode(5) for TDecimate. The differences in FPS and output bit rate were nominal, and to my eyes they look the same.

[LigH]

The problem with IVTC in general is that if an instance of the filter gets to see not every frame, but only a part of the whole video (what multi-threading by separating the clip among several instances may cause), it won't detect the Telecine pattern reliably, and therefore not revert it correctly. I guess the risk will be low because TFM has a large window, nevertheless it is not impossible.

[LouieChuckyMerry]

The problem with IVTC in general is that if an instance of the filter gets to see not every frame, but only a part of the whole video (what multi-threading by separating the clip among several instances may cause), it won't detect the Telecine pattern reliably, and therefore not revert it correctly. I guess the risk will be low because TFM has a large window, nevertheless it is not impossible.

Thanks for the lucid explanation. I'll edit my script so TDecimate has SetMTMode(5), thus eliminating the possibility.

[real.finder]

According to what I remember, in 2012 with vfr encoding using tivtc 2pass I had to use SetMTMode(5) or SetMTMode(6) unless it will tell me that frames numbers does not match, but recently I tried use SetMTMode(2) and it work!

[tobindac]

Any chance for an 64bit version? It seems it could be used in an SVP 64bit version (http://www.svp-team.com/forum/viewtopic.php?pid=48306#p48306).

[LigH]

The original AviSynth project depends quite a lot on programming tricks which could not easily be ported to 64 bit software without crashing a lot. The 64 bit version of AviSynth 2.x does exist but never developed far. Therefore, plugin developers didn't care much about porting their software either.

AviSynth+ was started as a major rewrite from the kernel on, to be able to support both 32 and 64 bit builds. If you need a 64 bit AviSynth, try the "plus" fork. Or maybe change to VapourSynth, which works differently, but supports many similar features and plugins.

[Boulder]

Hello. Is there any way to include a MT-non compatible filter (that requires a single instance only) between two plugins, running in MT? This plugin must run in one instance or works incorrectly.

...
SetMTMode(2)
Filter_in_MT()
Filter_without_MT()
Filter_in_MT()
...

Also I would get a solution to change MT threads on different parts.
Just use:
...
SetMTMode(2)
Filter_in_MT()
SetMTMode(5) # or try SetMTMode(3)
Filter_without_MT()
SetMTMode(2)
Filter_in_MT()
...

I do that with TDecimate all the time and it works fine.

[Boulder]

In such cases, you might be better off using MT_Pipeline: http://forum.doom9.org/showthread.php?t=163281. It could be difficult to combine MT things though.

[speedyrazor]

Does anyone know which version of the SoundTouch library is being used in this latest MT version, 2015.02.20 ?
I am hoping it's 1.8 as this has multi channel audio support for audio TimeStretch, updated over 1 year ago.

Cheers.

[LigH]

It would contain the same version as the latest (non-MT) AviSynth release.

The only relevant entry in the readme.txt of AviSynth 2.6.0 RC 3 [150419] (http://netcologne.dl.sourceforge.net/project/avisynth2/AviSynth_Alpha_Releases/AVS%202.6.0%20RC%203%20%5B150419%5D/readme.txt) was: "Updated Soundtouch to 1.31 (2.5.8)" ... not mentioned again since.

[foxyshadis]

Another question is to get a better solution to make my own MT-compatible plugin with a huge array in the plugin constructor (>200MB). I have many LUT tables.

It seems when I use it in MT, I get many instances of that plugin, so on Intel i7 with 8 threads it is too big to use on 32-bit system even with 3GB patched host. mt_masktools creates also many LUT tables, so I looking for a solution to fix this issue before we have no 64-bit version of Avisynth. My scripts are very complex, so I have memory problem on 2K sources. Disabling of MT is very sloooooooow. So a workaround I use is 2 threads in Set MT Mode.

Mode 1 is single-instance MT. Be very careful and absolutely certain that your plugin is re-entrant before using it, though. Stick to local variables as much as possible.

[speedyrazor]

I want to run 4 separate instances at the same time using Avisynth MT, running in a bespoke application, sending to ffmpeg. Here is the server spec I am using:

Windows Server 2012
Dual Xeon E5-2650 v2 (16 cores, 32 threads)
128 GB Ram

And here is the current code I am using, which I am sending to ffmpeg:

SetMemoryMax(400)
SetMTMode(3)
QTInput("test.mov", quality=100, audio=2)
SetMTMode(2)
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
SmoothDeinterlace()
Spline36Resize(720, 576)
TimeStretchPlugin(tempo = 25.0/24.0*100.0)
AssumeFPS(25, 1)
Distributor()

Currently the results I am seeing are indifferent, some crashing, instability, etc.
So my question is, is it possible to run 4 separate instances of Avisynth MT, and if so is the above script OK, or should it be tweaked?

Kind regards.

[LigH]

Most important: Whether or not to use Distributor() depends a lot on the situation. Most applications using VfW or the AviSynth API won't need it; I know that scripts inside the ffdshow PP filter may need it.

[LigH]

AviSynth 2.60 went "final".

So, new MT build, please? :)

[Ajvar]

That would be awesome.

[Groucho2004]

Guys, don't get your knickers in a twist. The only change in the code for avisynth.dll after the current MT version was posted by SEt is this (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/cache.cpp?r1=1.41&r2=1.42).
I'm not sure if this is even relevant since the MT version has it's own cache management.

However, it would give some folks peace of mind, I guess.

[LouieChuckyMerry]

I was hoping that someone more knowledgeable than I could save me days of testing time by offering experience-based suggestions for "translating" a stable MT AviSynth-FFMSIndex script into a stable MT AviSynth-DGIndex script. That is, any rational ideas for tweaking the MT settings for the following stable script so that it also runs stably with DGIndex would be much appreciated:

# Set DAR in encoder to 6480 : 4739. The following line is for automatic signalling
global MeGUI_darx = 6480
global MeGUI_dary = 4739
SetMemoryMax(256)
SetMTMode(3,3)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\ffms\ffms2.dll")
FFVideoSource("SourcePath", fpsnum=30000, fpsden=1001, threads=1)
### Deinterlace ###
SetMTMode(5)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
TFM(Field=0,Mode=5,PP=1,Slow=2,CThresh=4)
TFM(Field=1,Mode=5,PP=1,Slow=2,CThresh=4)
TFM(Order=-1,Slow=2,CThresh=4)
TDecimate(Mode=1,Cycle=15,CycleR=3)
SetMTMode(2)
Vinverse()
### Deshaker ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
RatioResize(10/11.0,"PAR")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",thY1=20,thY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(dfttest(),Mask,Luma=True)
### Overall Temporal Denoise, Could Probably Be Optimized ###
SMDegrain(tr=2,thSAD=600,ContraSharp=True,RefineMotion=True,Plane=0,Lsb=True,Lsb_Out=True,PreFilter=2)
### Debanding ###
GradFun3(thR=0.55,Radius=12,Mask=2,SMode=1,Lsb=True,Lsb_In=True, StaticNoise=True,Y=3,U=3,V=3)
DitherPost(Stacked=True,Prot=False,Mode=0)
### Line Darkener And Thinner ###
FastLineDarkenMod(Strength=20,Prot=6,Thinning=0)
aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)

Currently if I use the same MT settings with DGIndex the result is a frozen MeGUI (or AVSMeter), but given my lack of knowledge regarding the workings of FFMSIndex and DGIndex, I've no idea where to start tweaking. Thanks for your time :) .

[Morte66]

I have a feeling this has been asked before, but my google fu has failed me.

I want to use TTempSmoothF on the end of avisynth scripts, after other temporal filters. As best I can tell it is not happy with AvisynthMT, even in mode 5, unless it is the first Temporal filter in the script.

So I can run a script like:
SetMtMode(3)
FFVideoSource(etc)
SetMtMode(5)
#crop, levels, any spatial filters
TTempSmoothF(maxr=7)
... and it's OK but only uses one core

But if I use something like:
SetMtMode(3)
FFVideoSource(etc)
SetMtMode(2)
#crop, levels, any spatial filters
QTGMC() #or other filters/scripts with a temporal radius
SetMtMode(5)
TTempSmoothF(maxr=7)
.... the latter runs, but it sits at about 50% cpu on my quad core and goes pretty slow (about twice as fast as I'd get with regular Avisynth, on four cores). As best I recall (it's been years), this was a known problem with TTempSmooth and AvisynthMT, something to do with blocking maybe.

What I do at the moment is run my main script to lossless, then a second script from the lossless which just does TTempSmooth in mode 5. I run multiple such jobs in parallel to load the cpu, with trim statements to split up a job. I used to use the external filter MT, e.g. MT('TTempsmoothF(maxr=7)',threads=4,overlap=8,splitvertical=true) but MT.dll has gone from 2.6.

So, I wonder, does anybody know...
- Is this a known problem, or am I imagining that?
- Did anybody find a way around it? Can I somehow run e.g. MVTools then TTempSmooth smoothly in AvisynthMT 2.6?
- Is MT.dll really gone and not coming back?

[Ajvar]

It's safe to assume that SET is either out of reaching or isn't going to do this. Is anyone else who could make MT patch?

[Groucho2004]

It's safe to assume that SET is either out of reaching or isn't going to do this. Is anyone else who could make MT patch?
What problem do you have with the current version?

[Keiyakusha]

What problem do you have with the current version?

For example, AVSmeter is NOT saying that the avisynth version is 2.6.0.6 ^__^

[Livesms]

Do we need to recompile something again or is it a bug:Its issue known, its necessary that should be fixed in mt_masktools_26.dll.

http://forum.doom9.org/showthread.php?p=1589904#post1589904

http://forum.doom9.org/showthread.php?p=1589960#post1589960

http://forum.doom9.org/showthread.php?p=1610927#post1610927

What can I do with CACHE_GETCHILD_CACHE_MODE error ?

[LigH]

As documented several times during the last year: Use a special patched version of mt_masktools26.dll (http://forum.doom9.org/showthread.php?p=1619023#post1619023) (06_taro's fix for Vit's fix) to be compatible with AviSynth MT 2.6 RC4 and newer.

It may be hard to search this error message using the forum search, but Google [ site:forum.doom9.org CACHE_GETCHILD_CACHE_MODE ] returned some matches.

[Livesms]

As documented several times during the last year: Use a special patched version of mt_masktools26.dll (http://forum.doom9.org/showthread.php?p=1619023#post1619023) (06_taro's fix for Vit's fix) to be compatible with AviSynth MT 2.6 RC4 and newer.

It may be hard to search this error message using the forum search, but Google [ site:forum.doom9.org CACHE_GETCHILD_CACHE_MODE ] returned some matches.
Thanks...
Helped. Also forgot to add "SetMTmode(2)" to the very first line of avs Script ...

[Reel.Deel]

I would recommend the updated MaskTools b1 (https://github.com/tp7/masktools/releases).