Avisynth+

[ryrynz]

Hopefuly I will also find why Prefetch(1) is the same as Prefetch(0) and fix it.


Was this ever resolved?

[MysteryX]

Is there some documentation about the new 16-bit functions? What functions are supported, how to convert between formats, etc.

For example, how can I convert to 16-bit and then convert from Rec601 to Rec709, if that's supported?

Also several of the existing plugins will have to support 16-bit input and output in addition to lsb_in_out; shouldn't be hard to do when they already handle 16-bit but it just needs to be done.

[pinterf]

At the present state only YUV color spaces have high bit-depth support: 16 bit and float (32 bit).

In the last five weeks from the project start, we had no time for RGB48/64 and 10-12-14 bit support, but they will be done of course soon. At least defining the constants, names, and the basic conversions to and from. In order to let the filter authors play with them also.

Color space naming conventions:
8 bit:

Y8, YV12, YV16, YV24

16 bit:

Y16, YUV420P16, YUV422P16, YUV444P16

float:

Y32, YUV420PS, YUV422PS, YUV444PS


Bit-depth conversions (no dithering, no range conversion, etc...)

ConvertTo8bit()
ConvertTo16bit()
ConvertToFloat()

Color-space conversions within same bit-depths (also works for 8 bit)

ConvertToY()
ConvertToYUV420()
ConvertToYUV422()
ConvertToYUV444()

Their parameters are the same as at their 8 bit counterparts:

ConvertToY8(), ConvertToYV12(), ConvertToYV16(), ConvertToYV24()

Compatibility conversions for existing 16 bit hacked formats:

ConvertFromStacked()
ConvertToStacked()
ConvertFromDoubleWidth()
ConvertToDoubleWidth()

Plane swap

UToY(), VToY()
UToY8(), VToY8()
YToUV()

The UToY8 and VToY8 naming is still illogical at the moment, because it makes Y8 Y16 or Y32 clip depending on the source.
But with removing the '8' specifier from the name, it would collide with UToY and VToY

Internal filters.
I made a list from here (http://avisynth.nl/index.php/Internal_filters) where I saw Y8 or YUV support.

See the functions below that have NO 16bit/float port yet.

Color conversion and adjustment filters

ColorYUV
Invert
Levels
Limiter
MergeARGB / MergeRGB

Overlay and Mask filters

MaskHS
Overlay
Subtract

Geometric deformation filters

SkewRows (do we need it? affects only Y8?)

Debug filters

ColorBars / ColorBarsHD
Compare
Histogram


Output
See Chikuzen's avs2pipe mod (http://forum.doom9.org/showthread.php?p=1774532#post1774532)

I hope I have not missed important points, so please test, comment, (ask for features), and as ultim had said, treat it as a beta.

And remember that introducing high bit-depth into Avisynth+ was a must have but is not enough. Writing supporting filters and porting the old ones is very important. If you are not a programmer you can still force the otherwise boring authors :)

[vcmohan]

In this newer version of AVS+ how can a plugin know the bits per channel (apart from the unweildy names)? can any of the following calls
int (VideoInfo::*BitsPerPixel)() const;
int (VideoInfo::*BytesPerChannelSample)() const;
used to get info? Can one ask if it is planar and then bits pr channel? Presume that like vapoursynth 10,12,14 bit depth channels will be expanded to 16 bit and presented to the plugin to process.

[pinterf]

In this newer version of AVS+ how can a plugin know the bits per channel (apart from the unweildy names)? can any of the following calls
int (VideoInfo::*BitsPerPixel)() const;
int (VideoInfo::*BytesPerChannelSample)() const;
used to get info? Can one ask if it is planar and then bits pr channel? Presume that like vapoursynth 10,12,14 bit depth channels will be expanded to 16 bit and presented to the plugin to process.
VideoInfo has a new function: ComponentSize() which tells you how many bytes needed for a pixel sample.
1, 2 and 4 means: byte, uint16_t, and float pixel type, respectively.

The 10-12-14 bit versions are not implemented yet, but the ComponentSize() function for such colorspaces will return 2 bytes in the future.
Avisynth internal filters also use this function for deciding whether 8 bit / 16 bit / float processing should be done.
Alternatively (for YUV only) BytesFromPixels(1) will tell you the same.

Warning: using these functions of course will fail on classic avisynth or earlier avs+ builds.

So there will be a yet-to-be-named function for requesting the internal bit depth format of the specific color space.

What you wrote:
BitsPerPixel has other purposes, and cannot be used in a globally logical way, e.g. it returns 32 for RGB32, 24 for RGB24, etc.
BytesPerChannelSample is for audio.

One can of course make magic directly from the bitmap of pixel_type property, currently its the layout is under revision (but will remain compatible with the old things)

[ultim]

VideoInfo has a new function: ComponentSize() which tells you how many bytes needed for a pixel sample.
1, 2 and 4 means: byte, uint16_t, and float pixel type, respectively.

The 10-12-14 bit versions are not implemented yet, but the ComponentSize() function for such colorspaces will return 2 bytes in the future.
Avisynth internal filters also use this function for deciding whether 8 bit / 16 bit / float processing should be done.
Alternatively (for YUV only) BytesFromPixels(1) will tell you the same.

Warning: using these functions of course will fail on classic avisynth or earlier avs+ builds.

So there will be a yet-to-be-named function for requesting the internal bit depth format of the specific color space.

What you wrote:
BitsPerPixel has other purposes, and cannot be used in a globally logical way, e.g. it returns 32 for RGB32, 24 for RGB24, etc.
BytesPerChannelSample is for audio.

One can of course make magic directly from the bitmap of pixel_type property, currently its the layout is under revision (but will remain compatible with the old things)

When 10/12/14 get added, will BitsPerPixel() return the number of useful bits, or the number of bits used for storage? So for example, for 10bit video, should BitsPerPixel() return 10*NumComponents(), or 8*ComponentSize()*NumComponents() ?

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.

[ultim]

Was this ever resolved?

Not yet. I'm planning to have a sweep at the thread pools and it might turn something up, but the issue you mentioned was never important enough or had any direct consequences for the user for me to have look at.

[Chikuzen]

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.

10bit and 14bit will have the great difference for many filters which using SIMD.

[pinterf]

When 10/12/14 get added, will BitsPerPixel() return the number of useful bits, or the number of bits used for storage? So for example, for 10bit video, should BitsPerPixel() return 10*NumComponents(), or 8*ComponentSize()*NumComponents() ?

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.
In the core BitsPerPixel is used mostly in the RGB part, for calculating the byte size of a whole interleaved pixel (24>>8 = 3 bytes, 32>>8 = 4 bytes). I don't know how external plugins use it.
The 10-12-14 bit is mostly important for export/import. Although many basic external filters still do not support even the basic 8 bit color spaces, have issues at 64 bit environment, making them work at 16 bits is a dream. But let's don't cut the possibility if a filter is modern and can distinguish between 10-12-14 bits. Before we met, I had just looked at KNLMeansCL, and it used this bit count properly at its VapourSynth part.

Chikuzen, can you tell examples?
What I guess, smaller bit size can really have advantages, for 10 bits xy luts can work. At 14 bits we can use signed 16 bits in SIMD, unsigned 16 bit data sometimes requires SSE 4.2 or workarounds at SSE2. These are not frequent cases though, but when someone explicitely prepares his plugin for these bitdepth, he may really need them.

[tormento]

I fixed a false positive in the diagnostic messages and pulled pinterf's latest high bit-depth work in r2076.

mmm... video decoder errors with DGNV.

Can somebody please upload the previous version?

EDIT: confirmed... with r2043 (the only other in mirror) it works. Please upload r2069 back ;)

[pinterf]

mmm... video decoder errors with DGNV.

Can somebody please upload the previous version?

EDIT: confirmed... with r2043 (the only other in mirror) it works. Please upload r2069 back ;)
Refine that error report, please. Missing ConvertToPokemon() or what?

[tormento]

Refine that error report, please. Missing ConvertToPokemon() or what?

CUDA Error!

And then Unable to create Video Decoder.

P.S: As an Ingress agent, that is a bad word to me ;)

[Groucho2004]

CUDA Error!

And then Unable to create Video Decoder.

P.S: As an Ingress agent, that is a bad word to me ;)
How about posting the script? You should know the drill.

[tormento]

How about posting the script? You should know the drill.

Nothing changed, only AviSynth+ from r2069 to latest.

Anyhow:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\1_52 quinta onda, La\quinta.dgi")

ChangeFPS(last,last,true)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6,TV_range=true)

Prefetch(8)

Please, anybody, upload r2069 somewhere so I can test it back.

[Groucho2004]

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6,TV_range=true)
"SMDegrain does not have a named argument "TV_range""
So, which of the 357 versions of SMDegrain are you using?

Took out the "tv_range" parameter. With "Prefetch(2)" I'm already at 750 MB graphics memory. However, it runs.

[tormento]

"SMDegrain does not have a named argument "TV_range""
So, which of the 357 versions of SMDegrain are you using?

Remove that parameter. Anyhow I am using this (http://forum.doom9.org/showthread.php?p=1771735#post1771735)

Nobody has a r2069 copy on HD?

[Groucho2004]

Remove that parameter.
I edited my post. Your script works fine for me (XP64) but I have to lower the number of threads because of memory limits.

[ultim]

Remove that parameter. Anyhow I am using this (http://forum.doom9.org/showthread.php?p=1771735#post1771735)

Nobody has a r2069 copy on HD?

Please wait a few hours, will be fixed today. Pinky promise. (I'd rather give you a fixed build instead of having you test an older older version with other known flaws.)

[tormento]

Please wait a few hours, will be fixed today. Pinky promise. (I'd rather give you a fixed build instead of having you test an older older version with other known flaws.)

Have to encode a movie for tonight. :) r2069 is more than enough for me now

[ultim]

mmm... video decoder errors with DGNV.

Can somebody please upload the previous version?

EDIT: confirmed... with r2043 (the only other in mirror) it works. Please upload r2069 back ;)

remove SetFilterMTMode("DGSource", 3) until fix.

[tormento]

remove SetFilterMTMode("DGSource", 3) until fix.

Wow. That was fast and easy :)

[MysteryX]

I did some benchmark tests of various MT implementations here. (http://forum.doom9.org/showthread.php?p=1773672#post1773672)

Let's try again with r2076

Plain script

ColorBarsHD(width=800, height=600, pixel_type="YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (min | max | average): 2.450 | 1000000 | 26.85
Memory usage (phys | virt): 356 | 382 MiB
Thread count: 68
CPU usage (average): 4%
**it is instead using MT_MULTI_INSTANCE. If I set Force=true, it freezes on init.

MT_NICE_FILTER
FPS (min | max | average): 2.522 | 1000000 | 23.71
Memory usage (phys | virt): 245 | 264 MiB
Thread count: 28
CPU usage (average): 4%
**Was 23.51, it is slightly faster

2 Engines
FPS (min | max | average): 2.926 | 1000000 | 26.90
Memory usage (phys | virt): 289 | 309 MiB
Thread count: 33
CPU usage (average): 4%
**Same, but higher memory usage (309MB vs 279MB)


Let's try on my full script to upscale 288p to 768p. Script includes KNLMeans, 2x SuperResXbr, InterFrame and various 16-bit tools.

MT_SERIALIZED
Again, freezes if I force MT_SERIALIZED and it used MT_MULTI_INSTANCE instead.

MT_NICE_FILTER
FPS (min | max | average): 1.414 | 1000000 | 12.88
Memory usage (phys | virt): 966 | 1058 MiB
Thread count: 125
CPU usage (average): 29%
**Lower performance and higher memory usage. Before:
FPS (min | max | average): 3.436 | 1000000 | 13.27
Memory usage (phys | virt): 680 | 736 MiB
Thread count: 52
CPU usage (average): 27%

No point in setting 2 engines because there are already 2 shader functions


or let's try heavier GPU processing with complex CPU work

ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SMDegrain(thsad=200, prefilter=2, lsb=true)
SuperResXBR(5, 1, .15, fWidth=2600, fHeight=1500, fKernel="SSim", Engines=1)
Prefetch(8)

MT_SERIALIZED
** Cannot yet test

MT_NICE_FILTER
FPS (min | max | average): 0.347 | 1000000 | 3.176
Memory usage (phys | virt): 1125 | 1162 MiB
Thread count: 34
CPU usage (average): 29%
**Slightly higher performance with lower CPU usage

2 Engines
FPS (min | max | average): 0.233 | 1000000 | 2.715
Memory usage (phys | virt): 1197 | 1236 MiB
Thread count: 39
CPU usage (average): 31%
**Still the same lower performance anomaly


I want to test MT_SERIALIZED but it's not yet working for me.

The higher memory usage might be due to some filters running in MT_MULTI_INSTANCE instead of MT_SERIALIZED.

[ultim]

I did some benchmark tests of various MT implementations here. (http://forum.doom9.org/showthread.php?p=1773672#post1773672)
...

I'm home now finally, and am looking at the issue tormento reported in greater detail. I'll have a fix soon as it is not hard but the consequences of the problem were pretty severe. Please redo your tests with the build I'll publish soon.

[ultim]

Okay, r2082 (http://avs-plus.net/builds) has an important fix for a bug that made some filters use the default MT mode instead of the specified one under certain conditions. It was the cause for tormento's problem. Additionally another case of false positives was cured for the generated diagnostic logs, and pinterf's latest work is integrated adding support for high bit-depth blur and sharpen.

[tormento]

Okay, r2082 (http://avs-plus.net/builds) has an important fix for a bug that made some filters use the default MT mode instead of the specified one under certain conditions. It was the cause for tormento's problem. Additionally another case of false positives was cured for the generated diagnostic logs, and pinterf's latest work is integrated adding support for high bit-depth blur and sharpen.

Problem solved :thanks:

[ultim]

MysteryX, I took a quick look at your source of AviSynthShader to verify something. Whenever you call GetFrame() (https://github.com/mysteryx93/AviSynthShader/blob/master/Src/ExecuteShader.cpp#L115) to get your input frames, pull those calls out of your mutex lock! The way your filter operates right now is forcing the other filters it calls into mode 3! Not nice.

The occurance I linked to might not be the only one, it was just the first I've found.

[MysteryX]

MysteryX, I took a quick look at your source of AviSynthShader to verify something. Whenever you call GetFrame() (https://github.com/mysteryx93/AviSynthShader/blob/master/Src/ExecuteShader.cpp#L115) to get your input frames, pull those calls out of your mutex lock! The way your filter operates right now is forcing the other filters it calls into mode 3! Not nice.

The occurance I linked to might not be the only one, it was just the first I've found.
Oh! That is one is very easy to fix: move the unique_lock down a few lines.

Good catch, I never thought about that.

By the way, does the new 16-bit code have ASM optimization or is only C++ code?

[MysteryX]

Let's try the benchmarks again with r2082

Original results here (http://forum.doom9.org/showthread.php?p=1773672#post1773672)

First, this line doesn't work. SetLogParams("stderr", INFO). INFO or DEBUG is not recognized.

MT_SERIALIZED still freezes with the way I have GetFrame inside the lock. If I fix that in my code, then it works.

Plain script

ColorBarsHD(width=800, height=600, pixel_type="YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (min | max | average): 1.561 | 1000000 | 23.02 (was 22.75)
Memory usage (phys | virt): 257 | 277 MiB (was 215MB)
Thread count: 28
CPU usage (average): 2%

MT_NICE_FILTER
FPS (min | max | average): 2.510 | 1000000 | 23.70 (was 23.51)
Memory usage (phys | virt): 250 | 269 MiB (was 238mb)
Thread count: 28
CPU usage (average): 4%

2 Engines
FPS (min | max | average): 2.169 | 1000000 | 26.80
Memory usage (phys | virt): 281 | 300 MiB
Thread count: 33
CPU usage (average): 4%

Let's try on my full script to upscale 288p to 768p. Script includes KNLMeans, 2x SuperResXbr, InterFrame and various 16-bit tools.

MT_SERIALIZED
FPS (min | max | average): 1.778 | 1000000 | 13.03 (was 7.930)
Memory usage (phys | virt): 644 | 698 MiB (same as before)
Thread count: 52
CPU usage (average): 27%

MT_NICE_FILTER
FPS (min | max | average): 2.977 | 1000000 | 13.25
Memory usage (phys | virt): 679 | 734 MiB
Thread count: 53
CPU usage (average): 27%

No point in setting 2 engines because there are already 2 shader functions


or let's try heavier GPU processing with complex CPU work

ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SMDegrain(thsad=200, prefilter=2, lsb=true)
SuperResXBR(5, 1, .15, fWidth=2600, fHeight=1500, fKernel="SSim", Engines=1)
Prefetch(8)

I keep getting this warning
WARNING: Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax().

MT_SERIALIZED
FPS (min | max | average): 0.247 | 1000000 | 3.002 (was 1.729)
Memory usage (phys | virt): 1091 | 1121 MiB (was 1044mb)
Thread count: 34
CPU usage (average): 27%

MT_NICE_FILTER
FPS (cur | min | max | avg): 3.368 | 0.349 | 1000000 | 3.108
Memory usage (phys | virt): 1084 | 1117 MiB
Thread count: 34
CPU usage (current | average): 27% | 28%

2 Engines
FPS (min | max | average): 0.149 | 1000000 | 2.536 (was 2.713)
Memory usage (phys | virt): 1224 | 1261 MiB
Thread count: 39
CPU usage (average): 31%
** this last one has gone worse than before, I'm wondering what's going on here


MT_SERIALIZED is now working much better than before, and MT_NICE_FILTER with a lock still works better.

The under-utilization of the GPU when running a single engine has been improved, somehow.

[pinterf]

Could you benchmark the last one with
a.) higher SetMemoryMax(), e.g. 2500? In such low memory situation the continuous cache shrink can really degrade performance
b.) Prefetch sequence (4-5-6-7), maybe the sweet spot is not at 8, even if you feed the script into avsmeter instead of running an encoder after it.

New high bit-depth filter routines are mostly in c. The main goal now is to have a working version of them, later they can get simd optimalization.

[ultim]

Thanks for the tests. Nice to see the improvements to MT_SERIALIZED are really paying off, in your case they practically doubled the performance.

First, this line doesn't work. SetLogParams("stderr", INFO). INFO or DEBUG is not recognized.

Yep it doesn't, because you're using it wrong. As documented in the announcement post, the constants are called LOG_INFO, LOG_DEBUG etc.

I keep getting this warning
WARNING: Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax().

This is one of the many new warnings introduced in r2069, helping you diagnose performance and other problems. Having to call SetMemoryMax() in AviSynth to increase the available memory is nothing new and goes way back to before Avs+ even existed. What is new now is that now you get notified if using it would be beneficial.

[Groucho2004]

First, this line doesn't work. SetLogParams("stderr", INFO). INFO or DEBUG is not recognized.

I admit that there's a hint of ambiguity in ultim's description of the function but even a miniscule amount of common sense would compensate for it:
Avs+ received a logging facility. You can enable it using SetLogParams(target, level) at the beginning of your script. 'target' can be either "stderr", "stdout", or a path to a file. Level is LOG_ERROR/WARNING/INFO/DEBUG (not strings), with increasing verbosity.

How anyone would think that "ERROR" has a "LOG_" prefix but all the other levels don't is peculiar at best, particularly for someone who considers himself to be a developer.

[ultim]

I admit that there's a hint of ambiguity in ultim's description of the function but even a miniscule amount of common sense would compensate for it:


How anyone would think that "ERROR" has a "LOG_" prefix but all the other levels don't is peculiar at best, particularly for someone who considers himself to be a developer.

Ah, OK, I see where the confusion comes from. I'll go back and edit the post for more clarity.

[MysteryX]

I admit that there's a hint of ambiguity in ultim's description of the function but even a miniscule amount of common sense would compensate for it:


How anyone would think that "ERROR" has a "LOG_" prefix but all the other levels don't is peculiar at best, particularly for someone who considers himself to be a developer.
Good feedback for Ultim, but you never miss a chance to insult :)

Taking a puff will help relieve the stress.

[thescrapyard]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail

[MysteryX]

The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail
You can try this
https://social.msdn.microsoft.com/Forums/vstudio/en-US/8392458e-c5dc-4fa4-a960-5b383b9aff2b/change-file-version-to-a-dll-without-recompile-it?forum=csharpgeneral

[Groucho2004]

You can try this
https://social.msdn.microsoft.com/Forums/vstudio/en-US/8392458e-c5dc-4fa4-a960-5b383b9aff2b/change-file-version-to-a-dll-without-recompile-it?forum=csharpgeneral
And you're complaining about insults? You're asking for them.

[real.finder]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail

you can install avs 2.6 and use mp_pipeline with ### dll: path with new avs+

I think avs+ should use another function to report version

something like PlusVersionNumber()

so the normal VersionNumber() will report the normal avs version that avs+ base on

[Groucho2004]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail
The Avisynth detection routine in AVS2DVD is flawed (as is the case with some other programs that attempt to detect Avisynth).

Most of these programs try something like this:
- Check if the registry pointer for the plug directory exists
- Check if the registry pointer for the install directory exists
- Check if "%ProgramFiles%"\Avisynth 2.5" exists
- Or - the worst I've seen - Check if "C:\Program Files\Avisynth 2.5" exists

All of the above methods are useless and don't even tell you if there's a working avisynth.dll and devil.dll in one of the directories to which the "%PATH%" environment variable points (i.e. system32/syswow64) which is all that's needed to have a working Avisynth environment.

Some, like AVS2DVD, do seem retrieve the file version of avisynth.dll but the detection fails elsewhere.

One can't properly detect Avisynth without some digging into the Win32 API and using IScriptEnvironment to get the file version, Avisynth interface version, etc.

[thescrapyard]

The Avisynth detection routine in AVS2DVD is flawed (and many other programs that attempt to detect Avisynth).

Most of these programs try something like this:
- Check if the registry pointer for the plug directory exists
- Check if the registry pointer for the install directory exists
- Check if "%ProgramFiles%"\Avisynth 2.5" exists
- Or - the worst I've seen - Check if "C:\Program Files\Avisynth 2.5" exists

All of the above methods are useless and don't even tell you if there's a working avisynth.dll and devil.dll in one of the directories to which the "%PATH%" environment variable points (i.e. system32/syswow64) which is all that's needed to have a working Avisynth environment.

Some, like AVS2DVD, do seem retrieve the file version of avisynth.dll but the detection fails elsewhere.

One can't properly detect Avisynth without some digging into the Win32 API and instantiating IScriptEnvironment to get the file version, Avisynth interface version, etc.



I've posted on the AVStoDVD forum, they are usually pretty quick with a response and fix if needed, suggesting to only check for the avisynth.dll and remove the version checks which would then allow me to use any release of avisynth+

[Groucho2004]

I've posted on the AVStoDVD forum, they are usually pretty quick with a response and fix if needed, suggesting to only check for the avisynth.dll and remove the version checks which would then allow me to use any release of avisynth+
MrC is already using AVSMeter to retrieve the clip properties, it should be simple to use it to get the Avisynth version details with the "-avsinfo" switch.

[ryrynz]

Not setting a default MT mode is giving me lower CPU time with one of my scripts than specifying mode 2 (mode 1 causes visual glitches and instability not surprisingly)
Another line removed from the script! That along with no longer needing to specify ffdshowsource's MT mode either is quite nice.

Just loving the stability & performance, so glad MT is in such great shape now. SEt's builds I think can now be laid to rest.
Could be about time for a release.

[MysteryX]

Not setting a default MT mode is giving me lower CPU time with one of my scripts than specifying mode 2 (mode 1 causes visual glitches and instability not surprisingly)
If it is neither 1 or 2, then what is the "default default"?

[ultim]

Not setting a default MT mode is giving me lower CPU time with one of my scripts than specifying mode 2

Is the difference really significant? I mean, are you sure it's not within the tolerance of measurement errors?

[Reel.Deel]

Ultim, there's a small problem with the latest release. If FFMS2 (v2.22) is in my autoload folder I get "Parse: Unrecognized exception!" with any script I to load. Even just a simple script with just ColorBars(). By removing FFMS2 it works as usual. I have not has this problem with prior Avs+ releases.

[Groucho2004]

Ultim, there's a small problem with the latest release. If FFMS2 (v2.22) is in my autoload folder I get "Parse: Unrecognized exception!" with any script I to load. Even just a simple script with just ColorBars(). By removing FFMS2 it works as usual. I have not has this problem with prior Avs+ releases.
Works fine for me (32 and 64 bit, XP64). Does AVSMeter -avsinfo reveal anything?

[Reel.Deel]

Works fine for me (32 and 64 bit, XP64). Does AVSMeter -avsinfo reveal anything?

No, I get the same "Parse: Unrecognized exception!" error.

[ultim]

No, I get the same "Parse: Unrecognized exception!" error.

Works for me too, both x86 and x64. For a more detailed inspection, I'm afraid I'm going to need to ask for your plugin directories. And make sure you're using r2082.

[Reel.Deel]

Ok, figured out the problem, I had FFMS2.avsi file in there as well from an earlier FFMS2 version. The odd thing is that is has always been there and have not had a problem until now.

Edit: The ffms2.avsi was from v2.21. updating to the latest script fixed it.

[Sparktank]

I've been getting "Parse: Unrecognized exception!", too.

Using Groucho's "Avisynth Version Switcher", but replacing with latest 2082 before running batch to 'install' AVSPLUS_x86.

Running just Avsmeter with no commands will crash and give the parse error.
Running AvisynthInfo will crash, too.

But, I notice, if I move all .avsi from the plugin folder to somewhere else not in the path, everything works.
I have to Import() manually for any of the .avsi (Dither_tools, v1.27.2), but everything still functions after that.

On a successful run of Avsmeter -info -log
Log created with: AVSMeter 2.3.1 (x86)
OS version: Windows 10 (x64) (Build 10586)

Avisynth version string: AviSynth+ 0.1 (r2082, MT, i386)
File version: 0.1.0.0
Avisynth Interface Version: 6
Muli-threading support: Yes
Linker/compiler version: 14.0
Avisynth DLL location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth DLL time stamp: 2016-07-22, 20:10:12
PluginDir2_5 (HKCU, x86): D:\AVS_Ver\\AVSPLUS_x86\plugins
PluginDir2_5 (HKLM, x86): D:\AVS_Ver\\AVSPLUS_x86\plugins

EDIT: Also latest MSVC redist installed.
Trying to run the redist with 2082, it asks if I want to repair.

[Reel.Deel]

Another problem, eedi3 v0.9.2.1 (https://github.com/Elegant996/EEDI3/releases) crashes AVSMeter with the following script (only tried with 32-bit so far):

SetFilterMTMode("eedi3_rpow2", 2) # don't matter which one I set, both crash
#SetFilterMTMode("eedi3", 2)

ColorBars(pixel_type="YV12")

eedi3_rpow2(2)

Prefetch(4)

There's no other plugins in the autoload directory other than eedi3 in the "plugins" folder and the core plugins in the "plugins+" folder.

Edit: replacing eedi3_rpow2 with eedi3() in the script above also crashes. BUT if you add threads=1 to both of them it works. Again, this use to work with earlier Avs+ versions.

Edit: also does not work with earlier Avs+ version. So it's not something that just happened recently.