Avisynth+

[ultim]

Just wondering why this is crashing my media player am using ffdshow raw.

SetFilterMTMode("", 2)
SetFilterMTMode("ffdshow_source", 3)
ffdshow_source()
Psharpen()
Prefetch(4)

I've tried stating Psharpen in a SetFilterMTMode as well but same deal. I just copied the Avisynth DLL into my SYSWOW64 folder. What am I missing?
Also is SetMemoryMax still something that should be set?

Hi,

I cannot try it right now because I don't have the necessary stuff installed. Does it work if you use SetFilterMTMode("", 3) instead?

[ryrynz]

It crashes even if the chain is left completely blank, which of course is no problem with 2.6 MT. Something's broken.

[TurboPascal7]

It crashes even if the chain is left completely blank, which of course is no problem with 2.6 MT. Something's broken.

Works fine (http://i3.minus.com/ibuBF0OZAJTvsH.jpg) here. Please ensure that you have correct x86 avisynth.dll in your SysWOW64 folder and x64 dll in System32 folder.
Also, are you using x64 ffdshow/mpc by any chance?

[ryrynz]

Yeah correct x86 version downloaded in SysWOW64, copied the x64 version to System32 as you said above (not required is it?) Am using MPC-HC/BE/ffdshow x86.
2.6 MT is working fine, just copied the 2.6MT version over the AVS+ version and BE/HC doesn't crash at all, I have no idea what's going on.

[turbojet]

Latest version resizer's are a bit faster but still about 2% slower than avisynth 2.60, it used to be 4% slower on amd fx8320.

[Nevilne]

divide=1 or divide=2 doesn't work in MAnalyse with avisynth+

super = MSuper()
backward_vectors = MAnalyse(super, isb = true)
forward_vectors = MAnalyse(super, isb = false)
MFlowBlur(super, backward_vectors, forward_vectors, blur=15)
working

super = MSuper()
backward_vectors = MAnalyse(super, divide=1, isb = true)
forward_vectors = MAnalyse(super, divide=1, isb = false)
MFlowBlur(super, backward_vectors, forward_vectors, blur=15)
black screen

[innocenat]

Latest version resizer's are a bit faster but still about 2% slower than avisynth 2.60, it used to be 4% slower on amd fx8320.

Can you also provide raw fps number? Also, what kernel did you use? As stated before, none of dev have AMD machine, so it isn't tested.

[qyot27]

Hi qyot27,

Could you please check these special builds for you if you experience the same problem with either of them? And if so, which one?
EDIT: lol, sry i forgot to post the link: https://mega.co.nz/#F!sZkDjKRD!ZZz7oQvYP6FQ0F0rAeYOoQ
Both builds crash immediately due to a SIGILL.

On a different computer (that has SSE2), though:
AviSynth_check.dll = error, truncation
AviSynth_nocheck.dll = error, truncation

[naoan]

Thanks for the build ultim, haven't tried much but fft3dgpu need mode 3 to operate without glitch.

[turbojet]

blankclip(1630,1920,1080,"YV12",23.976)
resize(1280,720)
measured with avsmeter 1.7.6

AVS+ 2.60
Lanczos3 116 132
Spline64 108 116
Bicubic 192 159
Bilinear 205 225
Bicubic being faster while the others are slower might be interesting.

[kypec]

... new test build[/B], r1689

Right, http://goo.gl/e0VFYn.

Can anyone be so kind and tell me how am I supposed to download comfortably from that MEGA folder? When I choose "Download as ZIP" it always got stuck at 10~13% in Firefox. When I choose standard download then I have to confirm manually each single file to be downloaded and folder hierarchy is lost, x86 & x64 files are mixed due to having identical names :angry: Not very user friendly and very error-prone IMO.

EDIT: I just tried with Chrome on Windows 7 - same issue with "Download as ZIP". :(

[ultim]

divide=1 or divide=2 doesn't work in MAnalyse with avisynth+

super = MSuper()
backward_vectors = MAnalyse(super, isb = true)
forward_vectors = MAnalyse(super, isb = false)
MFlowBlur(super, backward_vectors, forward_vectors, blur=15)
working

super = MSuper()
backward_vectors = MAnalyse(super, divide=1, isb = true)
forward_vectors = MAnalyse(super, divide=1, isb = false)
MFlowBlur(super, backward_vectors, forward_vectors, blur=15)
black screen

Will check at home.

[ultim]

Both builds crash immediately due to a SIGILL.

On a different computer (that has SSE2), though...
Ah yes, I forgot to mention this in the changelist, I'll go and edit shortly. Previous stable Avs+ have been compiled to SSE2 unknowingly, this has been already discovered and is fixed in the current MT build. SSE is still required though.

AviSynth_check.dll = error, truncation
AviSynth_nocheck.dll = error, truncation

I was afraid of this. Then I think this is something to be fixed in FFAudioSource(). The special test builds for you were the same as stable r1576 (which you said was still working), except I removed the audio caches. No changes, just pure code removal, so that the Cache filters becomes completely transparent for audio and call through directly to the source filter. So unless the audio cache has been doing something funky, I think this might be a problem in FFAudioSource(). I'm not 100% sure though, as I'm not familiar with the audio cache of old AviSynth.

[ultim]

Thanks for the build ultim, haven't tried much but fft3dgpu need mode 3 to operate without glitch.

Thx. This will probably be true for all filters that use the GPU. For these filters, there is nothing Avs+ can do about them, aside from using mode 3. Try to place these calls towards the beginning of your script to minimize the performance affect on other filters.

[zero9999]

Can anyone be so kind and tell me how am I supposed to download comfortably from that MEGA folder? When I choose "Download as ZIP" it always got stuck at 10~13% in Firefox. When I choose standard download then I have to confirm manually each single file to be downloaded and folder hierarchy is lost, x86 & x64 files are mixed due to having identical names :angry: Not very user friendly and very error-prone IMO.

EDIT: I just tried with Chrome on Windows 7 - same issue with "Download as ZIP". :(
AviSynth+-2.6.0.5-MT-r1689-g0d5dfb7.7z (https://files.line0.in/builds/AviSynth%2B-2.6.0.5-MT-r1689-g0d5dfb7.7z)
AvsPmod-2.5.1-r426-x86-04874ed.7z (https://files.line0.in/builds/AvsPmod-2.5.1-r426-x86-04874ed.7z)

[Groucho2004]

blankclip(1630,1920,1080,"YV12",23.976)
resize(1280,720)
measured with avsmeter 1.7.6

AVS+ 2.60
Lanczos3 116 132
Spline64 108 116
Bicubic 192 159
Bilinear 205 225
Bicubic being faster while the others are slower might be interesting.

Same script with i5 2500K @ 4GHz:
(There is no Lanczos3 so I left it out)
AVS+ r1689 2.60A5
Spline64 161 190
Bicubic 341 298
Bilinear 382 461

The relative differences seem roughly the same for Intel/AMD, Intel is just a lot faster.

[innocenat]

turbojet, Groucho2004: Would you guys also mind testing horizontal resizer only? (i.e. 1920x1080 to 1280x1080 etc.) Thank you in advance.

[Groucho2004]

turbojet, Groucho2004: Would you guys also mind testing horizontal resizer only? (i.e. 1920x1080 to 1280x1080 etc.) Thank you in advance.

blankclip(1630,1920,1080,"YV12",23.976)

AVS+ 2.60A5
Spline64resize(1280,1080) 211 250
Bicubicresize(1280,1080) 472 379
Bilinearresize(1280,1080) 472 571

[innocenat]

blankclip(1630,1920,1080,"YV12",23.976)

AVS+ 2.60A5
Spline64resize(1280,1080) 211 250
Bicubicresize(1280,1080) 472 379
Bilinearresize(1280,1080) 472 571

Thank you very much. It seems that it is not as fast as I initially tested and expected.

[Nevilne]

divide=1 or divide=2 doesn't work in MAnalyse with avisynth+

Will check at home.

Thanks


Thanks for the build ultim, haven't tried much but fft3dgpu need mode 3 to operate without glitch.

Thx. This will probably be true for all filters that use the GPU. For these filters, there is nothing Avs+ can do about them, aside from using mode 3. Try to place these calls towards the beginning of your script to minimize the performance affect on other filters.

But should there be such a huge performance hit? I have a heavy script which has setmtmodes 2,3 and 4 for fft3dgpu at the end, it runs at 9 fps and fft3dgpu doesn't slow it down at all.

avs+ runs it at 12 fps with mode 2 but if i choose mode3 for fft3dgpu it runs at 6 fps.
However, if i put prefetch before fft3dgpu script seems to run correctly, and at 16 fps.

[innocenat]

Just a note: having filter after Prefetch() will currently result in two group of pipelined filter: filter before Prefetch() will run in number of threads specify, while filter after Prefetch() will run in single, main thread. Not sure if this behaviour will change or not.

[qyot27]

Ah yes, I forgot to mention this in the changelist, I'll go and edit shortly. Previous stable Avs+ have been compiled to SSE2 unknowingly, this has been already discovered and is fixed in the current MT build. SSE is still required though.
Yeah, for my own builds with VS2013, I just disabled additional CPU optimizations completely (/arch:IA32), regardless of the fact that I do have an SSE-capable processor.

How much of an equivalent is /arch in MSVC to GCC's -msse/etc. parameters? Does it have an impact on the intrinsics (since the option to dis/enable them is different), or are the two completely separate and the /arch stuff just optimizes the C/C++ parts?

I was afraid of this. Then I think this is something to be fixed in FFAudioSource(). The special test builds for you were the same as stable r1576 (which you said was still working), except I removed the audio caches. No changes, just pure code removal, so that the Cache filters becomes completely transparent for audio and call through directly to the source filter. So unless the audio cache has been doing something funky, I think this might be a problem in FFAudioSource(). I'm not 100% sure though, as I'm not familiar with the audio cache of old AviSynth.
I'll have to see. From looking at FFMS2's audiosource.cpp, that error message is defined in the FFMS_AudioSource::GetAudio function, here:
https://github.com/FFMS/ffms2/blob/master/src/core/audiosource.cpp#L343

Not sure if anything particular jumps out, but I thought I'd still point to it.

[innocenat]

How much of an equivalent is /arch in MSVC to GCC's -msse/etc. parameters? Does it have an impact on the intrinsics (since the option to dis/enable them is different), or are the two completely separate and the /arch stuff just optimizes the C/C++ parts?


It only affect compiler-generated code. Unlike GCC/Clang, the flag has no effect on intrinsics. But we have dynamic dispatcher with pure-C path for every internal filter so multiple version of filter is chosen automatically at runtime.

[ultim]

But should there be such a huge performance hit? I have a heavy script which has setmtmodes 2,3 and 4 for fft3dgpu at the end, it runs at 9 fps and fft3dgpu doesn't slow it down at all.

avs+ runs it at 12 fps with mode 2 but if i choose mode3 for fft3dgpu it runs at 6 fps.
However, if i put prefetch before fft3dgpu script seems to run correctly, and at 16 fps.

Yes, everything that you showed here is nothing out of ordinary. If you put a mode 3 fiilter in your script, all filters before it will also be serialized, which is the cause of the performance hit. This is why I recommended earlier that if you have a mode 3 filter, try to put it towards the beginning, which minimizes this hit.

The solution that you have implemneted, putting fft3dgpu *after* Prefetch(), is also a perfect solution, and is even better than placing it just before the Prefetch() if you have nothing after fft3dgpu.

[ultim]

Yeah, for my own builds with VS2013, I just disabled additional CPU optimizations completely (/arch:IA32), regardless of the fact that I do have an SSE-capable processor.

How much of an equivalent is /arch in MSVC to GCC's -msse/etc. parameters? Does it have an impact on the intrinsics (since the option to dis/enable them is different), or are the two completely separate and the /arch stuff just optimizes the C/C++ parts?


I'll have to see. From looking at FFMS2's audiosource.cpp, that error message is defined in the FFMS_AudioSource::GetAudio function, here:
https://github.com/FFMS/ffms2/blob/master/src/core/audiosource.cpp#L343

Not sure if anything particular jumps out, but I thought I'd still point to it.

Oh, you get that error? Then I'm puzzled and even less sure than I was before. This definetely needs investigation.

[qyot27]

It only affect compiler-generated code. Unlike GCC/Clang, the flag has no effect on intrinsics.
Ah, I see.

Oh, you get that error? Then I'm puzzled and even less sure than I was before. This definetely needs investigation.
Correct. I did a little bit more testing, and it happens with both SSRC and ResampleAudio, with slightly different behavior (see below). Based on the wording of the error message, could it be that the resampling filters are requesting extra samples out of FFAudioSource that just aren't there, leading to the error?




The results are as follows:
SSRC = error message is thrown just before the end of the read, script exits immediately causing audio to be truncated at the end

ResampleAudio = error message is thrown immediately, script exits, empty output file

No resampling step(s) at all = output audio is 44056kHz, no error is thrown, read ends successfully with no truncation


Steps to reproduce:
Generate test video+audio with FFmpeg:
ffmpeg -f lavfi -i testsrc=duration=60:size=352x176:rate=30 -f lavfi -i aevalsrc="sin(440*2*PI*t):s=44100" -vcodec mpeg4 -acodec aac -strict experimental -t 60 output.mp4

Index the file:
ffmsindex -t -1 output.mp4

Script:
FFmpegSource2("output.mp4",atrack=-1,fpsnum=30000,fpsden=1000)
#SSRC(48000,fast=false)
AssumeFPS(29.97,sync_audio=true)
#SSRC(48000,fast=false)
#ResampleAudio(48000)
Uncomment for SSRC vs. ResampleAudio tests.

[turbojet]

What I meant by Lanczos3 is lanczosresize(taps=3) which is default.

Interesting that intel has the same kind of results, I don't have time to test horizontally only right now but I can do it in a few hours if it's still needed.

[kypec]

AviSynth+-2.6.0.5-MT-r1689-g0d5dfb7.7z (https://files.line0.in/builds/AviSynth%2B-2.6.0.5-MT-r1689-g0d5dfb7.7z)
AvsPmod-2.5.1-r426-x86-04874ed.7z (https://files.line0.in/builds/AvsPmod-2.5.1-r426-x86-04874ed.7z)
:thanks: although you might consider to replace secure https linking with standard non-secure http due to untrusted (self-signed) certificate issues for potential downloaders of your builds.

[naoan]

Thx. This will probably be true for all filters that use the GPU. For these filters, there is nothing Avs+ can do about them, aside from using mode 3. Try to place these calls towards the beginning of your script to minimize the performance affect on other filters.

Yeah it's like mode 5 in the old mt. Thanks for the tips but I need it last, and it's actually fast enough on my simple real time ffdshow-avisynth+ anyway (just it and fastlinedarkenmod).

[ultim]

Yeah it's like mode 5 in the old mt. Thanks for the tips but I need it last, and it's actually fast enough on my simple real time ffdshow-avisynth+ anyway (just it and fastlinedarkenmod).

If it needs to be last, you can also place it after the call to Prefetch().

[naoan]

If it needs to be last, you can also place it after the call to Prefetch().

Nice! didn't know you could do it like that, seems a bit faster/less frame drop now. Thanks! :D

[kypec]

AviSynth+-2.6.0.5-MT-r1689-g0d5dfb7.7z (https://files.line0.in/builds/AviSynth%2B-2.6.0.5-MT-r1689-g0d5dfb7.7z)
AvsPmod-2.5.1-r426-x86-04874ed.7z (https://files.line0.in/builds/AvsPmod-2.5.1-r426-x86-04874ed.7z)

I've replaced my Avisynth installation with your x86 build and also replaced AvsPmod files but now AvsPmod refuses to even start with error message below:
http://i57.tinypic.com/23ubvx1.jpg
Clicking "Yes" and navigating to C:\Windows\SysWOW64 where that Avisynth+ DLL resides does not work either. :(

[ryrynz]

Hoping for a build that works with ffdshow, tried it on both my computers win8/win7 i7/i5 and both crash instantly, both are working fine with 2.6MT.

[turbojet]

blankclip(1630,1920,1080,"YV12",23.976)
resize(1280,1080) AVS+ 2.6
Lanczos 139 153
Spline64 142 135
Bicubic 241 175
Bilinear 246 240


Same conclusion as Groucho2004's test with lanczos included.

[ultim]

So here are some more news I've promised. The list of our Google Summer of Code ideas is online! It is available from the homepage (http://avs-plus.net) with a single click, but here is a direct link (http://www.avs-plus.net/gsoc-ideas.php) for you. You'll find all kinds of interesting projects there, from native GPU support to scripting language improvements and a GUI plugin manager, just to name a few. Now, cross your fingers for AviSynth to be accepted.

[Stereodude]

Your direct link gives a 404.

I also have a question about AviSynth+. I see a big push related to MT in the past week. I thought the whole idea was to get better performance without requiring the user to mess around with MT commands and the like? I'm probably put off to the idea because my experience with MT support in AviSynth is that it's a complete disaster that barely works even on the rare occasions when the stars align just right and I'd not rather not have those headaches again. I've had much better luck with MP_Pipeline at speeding up scripts than I ever had with MT and it doesn't require any sort of celestial alignment or blood sacrifices.

[ultim]

Your direct link gives a 404.
Works for me.


I also have a question about AviSynth+. I see a big push related to MT in the past week. I thought the whole idea was to get better performance without requiring the user to mess around with MT commands and the like?
Ultimately, that is what everybody (including us developers) would like to see. But unfortunately what you wish for is simply technically not possible for many filters due to the way they work. What we can do though is to minimize the MT-related commands the user has to issue, instead of completely eliminating them. Minimizing the MT-commands for script writers is the collective goal of many of our efforts, such as many filter rewrites (both internal and external), adding support for filters to signal to Avs+ the MT mode they need, the way SetFilterMTMode() works, and even of this (http://forum.doom9.org/showpost.php?p=1649886&postcount=181) post to teach plugin developers how to support MT hassle-free for the user.

So we do what we can, but sometimes there are hard limits to what is possible at all.

[TurboPascal7]

I thought the whole idea was to get better performance without requiring the user to mess around with MT commands and the like?
That's right. When MT is finalized, the only thing the user will have to write in his script is the Prefetch call, which later can probably be added by programs like avsmeter, avs2yuv and the likes. All SetFilterMtMode calls will be hidden in a single .avsi script.

Compared to all those ### MT_Pipeline requires you to write, this is nothing.

Now, the problem is to build this avsi file with MT modes definitions. I put this pad (https://pad.riseup.net/p/avs_plus_mt_modes) about two weeks ago and posted the link on our IRC channel, ultim also linked it here a few days ago. But since the initial script, only one line has been added (fft3dgpu). With this kind of activity you can't expect MT to get finalized and become user-side overhead free any time soon.

[HeadlessCow]

That's right. When MT is finalized, the only thing the user will have to write in his script is the Prefetch call, which later can probably be added by programs like avsmeter, avs2yuv and the likes. All SetFilterMtMode calls will be hidden in a single .avsi script.

Compared to all those ### MT_Pipeline requires you to write, this is nothing.

Now, the problem is to build this avsi file with MT modes definitions. I put this pad (https://pad.riseup.net/p/avs_plus_mt_modes) about two weeks ago and posted the link on our IRC channel, ultim also linked it here a few days ago. But since the initial script, only one line has been added (fft3dgpu). With this kind of activity you can't expect MT to get finalized and become user-side overhead free any time soon.

Is there a reason why you couldn't require the filters to implement a new method that returns the MT modes that they support rather than relying on a community generated avsi script? You'd still need the script for older plugins, but anything new (or anything that you're updating) would just automatically work.

[TurboPascal7]

Is there a reason why you couldn't require the filters to implement a new method that returns the MT modes that they support rather than relying on a community generated avsi script? You'd still need the script for older plugins, but anything new (or anything that you're updating) would just automatically work.
No, there is no reason we couldn't do this. That's why we did. :) It works by abusing SetCacheHints (https://github.com/AviSynth/AviSynthPlus/blob/0d5dfb39f9b45a268884509f77022f604a14f4a7/avs_core/filters/transform.h#L63) right now but allows keeping backward compatibility.

[HeadlessCow]

No, there is no reason we couldn't do this. That's why we did. :) It works by abusing SetCacheHints (https://github.com/AviSynth/AviSynthPlus/blob/0d5dfb39f9b45a268884509f77022f604a14f4a7/avs_core/filters/transform.h#L63) right now but allows keeping backward compatibility.

Ah, perfect (and sneaky)! I hadn't seen mention of it in the thread, so I just wanted to make sure the obvious option hadn't been accidentally overlooked :-D

[turbojet]

Here's some results with fastest mt mode:

tfm 1
tdecimate 3 or off, 1 fails
telecide 1
decimate 3 or off, 1 and 2 fails
fielddeinterlace 2, 1 fails
dss2 1, 2 is very slow
lwlibavvideosource(dr=true) 2 is 25% faster with much higher cpu usage, 75 vs 17%, 1 fails
nnedi3 2, 1 corruption
colormatrix("Rec.709->Rec.601") 2 is <1% faster than all modes or off
dfttest 1
fdecimate 1 and 2 tie
it 3, 1 fails, 2 is same speed as 3 but 4x cpu load
jinc36resize(3840,2160) 2, 1 is corrupt
leakkerneldeint(1) 1
repal 3, 1 fails, 2 is slow
sorathread 3, 1 and 2 fails
srestore all tie
tdeint 1
unblend 1 or 2
uncomb 3 or off
unsharphq 1
yadif 1
yadifmod(edeint=nnedi3()) 2, 1 fails

All defaults unless (). When testing it's best to use a real source, some filters work on blankclip() but not on real sources
with the same mtmode.

Mode 1 works on quite a few things. One thing I didn't consider (much) is cpu load. I used prefetch(4) which 50% with most filters while mode 3 and off used 12%. mtmodes during realtime watching should be a big benefit but unless slow filters are used there's a little bit of a slowdown when x264 encoding.

[TurboPascal7]

Please do check if the actual output is correct. Fast but broken mode is useless.
I'm asking because for example nnedi3 with mode 1 is completely broken yet you specified it. I'm pretty sure that's the case with most filters in the list.
Easy way of checking would be using something like ColorBars(1920, 1080, "YV12").addgrainc(10000, 10000, seed=1) as a source filter. It doesn't always work right but will do for most stuff (like needi3).

[turbojet]

Does the corruption like nnedi3 only happen with mode 1?

[TurboPascal7]

Does the corruption like nnedi3 only happen with mode 1?
It most cases - yes.

Nnedi3 uses some buffers to do its dirty work and with mode 1 you get multiple threads writing data from different frames to the same buffer. This causes corruption when later someone tries to read from this buffer and gets not what was expected. Most of "more complicated" filters use some kind of temporary storage thus won't work well with this mode. Simple filters might.

Mode 2 doesn't have this issue because multiple threads will get their own buffers and no data will be shared. Hence mode 2 is the "default" mode which should work with most filters, but it wastes memory like crazy (take SangNom2 for example - for 1080p YV12 frame, size of temporary buffers is about 10MB, so with 4 threads you get 40MBs on single filter invocation. Now add some usual supersampling to this and multiple invocations in most aa scripts and... you get the idea).

If the filter requires sequential access or uses some global storage (i.e. written by a very bad person), then mode 3 is the only way to go.

[turbojet]

Tested all the reported 1's and other than nnedi3, jinc36resize didn't look correct. Others worked fine.

[ultim]

Ah, perfect (and sneaky)! I hadn't seen mention of it in the thread, so I just wanted to make sure the obvious option hadn't been accidentally overlooked :-D

It wasn't mentioned to avoid plugin writers accidentially using those parts of the new interface which are not safe. The MT-mode specification is safe, but be sure not to use IScriptEnvironment2 at all, for exmaple.

The good thing about MT-mode specification as shown by TurboPascal7, as he already noted, is that it keeps compatibility. So plugins can implemnent it without breaking older AviSynth versions, or non-plus AviSynth. Putting it into SetCacheHints() is ugly I know (TurboPascal7 was very much against it putting it there for this reason), but it is the only way for me to let plugins report their MT-mode without breaking other AviSynths.

Anyway, long story short, you can follow the example here (https://github.com/AviSynth/AviSynthPlus/blob/0d5dfb39f9b45a268884509f77022f604a14f4a7/avs_core/filters/transform.h#L63), but don't use any other part of the new interface yet. For plugins that report the MT mode using SetCacheHint(), the user won't have to add a SetFilterMode() call.

[LaTo]

What is a good way to detect Avisynth+ without losing compatibility with regular Avisynth?
I need that to automatically disable internal multi-threading in my filters.
Thanks.

[Groucho2004]

What is the best way to detect Avisynth+ without losing compatibility with regular Avisynth?
I need that to automatically disable internal multi-threading in my filters.
Thanks.
There are several ways to identify the avisynth.dll.

1. Query "AVISYNTH_INTERFACE_VERSION". This only tells you if it's 2.5x or 2.6x

2. Parse the version string ("VersionString"). A bit unreliable.

3. Parse the export functions. That's the most useful and what I do in AVSMeter. For example:
Only 2.6x versions export "DeleteScriptEnvironment()"
Only AVS+ exports "CreateScriptEnvironment2"
Only SEt's and tsp's MT versions export "GetMTMode()".

A combination of the above should provide enough info.

[jpsdr]

What is a good way to detect Avisynth+ without losing compatibility with regular Avisynth?
I need that to automatically disable internal multi-threading in my filters.
Thanks.

Should it be better to detect if MT mode is enabled ?
If someone use Avisynth+ without using multi-threading, i think internal multi-threading should be kept.