Avisynth+

[raffriff42]

"CombinePlanes: source and target plane dimensions are different"I think I found it:
avs_core\filters\planeswap.cpp, Line 870
int target_plane_width = vi_default.width >> vi_default.GetPlaneWidthSubsampling(current_target_plane);
int target_plane_height = vi_default.height >> vi_default.GetPlaneWidthSubsampling(current_target_plane);

[pinterf]

I think I found it:
avs_core\filters\planeswap.cpp, Line 870
int target_plane_width = vi_default.width >> vi_default.GetPlaneWidthSubsampling(current_target_plane);
int target_plane_height = vi_default.height >> vi_default.GetPlaneWidthSubsampling(current_target_plane);

Oops, thanks.

[pinterf]

CombinePlanes fixed, thanks for the report.

Download Avisynth+ r2506 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2506-MT)

20170608 r2506
- Fix CombinePlanes: feeding YV16 or YV411 target with Y8 sources

[edcrfv94]

after r1858 update to r2506.
r2506 will not load libfftw3f-3.dll under plugins+/plugins64+, libfftw3f-3.dll must under System32/SysWOW64.
It is a bug?

[Groucho2004]

after r1858 update to r2506.
r2506 will not load libfftw3f-3.dll under plugins+/plugins64+, libfftw3f-3.dll must under System32/SysWOW64.
It is a bug?No, it's a feature. :D

libfftw3f-3.dll is not a plugin, it's not supposed to be in the auto-load directory. It has to be either in the current directory, the same directory of the calling program or in a directory to which the "PATH" environment variable points. For simplicity, just put it in System32/SysWOW64.

[Sharc]

For the same source, same script and same x264 encoder settings (1-pass crf) I am getting about 45% bigger file size (and more noise) for AVS+ (x86) compared to AVS 2.6.0. How is this possible? :confused:

[sneaker_ger]

High bitdepth/dithering?

Show sample, scripts, program versions and logs.

[MysteryX]

I'm running FrameRateConverter with 1 thread

FrameRateConverter(60, output="auto")



FPS (min | max | average): 2.044 | 68778 | 12.90
Memory usage (phys | virt): 353 | 349 MiB
Thread count: 21
CPU usage (average): 13%


and with 8 threads

FPS (min | max | average): 2.332 | 129914 | 31.80
Memory usage (phys | virt): 785 | 784 MiB
Thread count: 29
CPU usage (average): 42%

What is causing such a bottleneck at 42% CPU usage?

[pinterf]

What is causing such a bottleneck at 42% CPU usage?
Are you using 32 or 64 bit Avisynth? What is your SetMemoryMax?
Perhaps try SetLogParams("log.txt", LOG_DEBUG) and look at the output. Is there any serialized mt mode filter in between?

[Sharc]

High bitdepth/dithering?

Show sample, scripts, program versions and logs.
I think I found the culprit. I am using in my script
temporalsoften(4,4,8,10,mode=2)
It seems to have no effect with AVS+ r2506, while it works as expected in AVS260.

[Groucho2004]

What is causing such a bottleneck at 42% CPU usage?I've noticed the same with John Meyer's simpler script. It has to be one (or a combination) of the mvtools2 functions that does not scale well with MT.

Edit: Throwing more threads at it seems to improve things without compromising efficiency (CPU with 4 cores/threads):

Prefetch(4):
FPS (min | max | average): 4.755 | 275350 | 48.26
Memory usage (phys | virt): 310 | 409 MiB
Thread count: 15
CPU usage (average): 66%
Efficiency index: 0.7312


Prefetch(6):
FPS (min | max | average): 17.36 | 167.1 | 57.60
Memory usage (phys | virt): 413 | 514 MiB
Thread count: 17
CPU usage (average): 79%
Efficiency index: 0.7292


Prefetch(8):
FPS (min | max | average): 14.93 | 4436 | 69.60
Memory usage (phys | virt): 527 | 628 MiB
Thread count: 19
CPU usage (average): 95%
Efficiency index: 0.7326


Prefetch(10):
FPS (min | max | average): 15.04 | 158387 | 72.15
Memory usage (phys | virt): 654 | 756 MiB
Thread count: 21
CPU usage (average): 99%
Efficiency index: 0.7288


Please note that this was done with John Meyer's script and an older version of mvtools2 (2.5.11.22) but the trend should be similar with your FrameRateConverter and pinterf's latest mvtools.

[pinterf]

I think I found the culprit. I am using in my script
temporalsoften(4,4,8,10,mode=2)
It seems to have no effect with AVS+ r2506, while it works as expected in AVS260.
r2506 is giving identical results to the very early (1576) avs+ versions.
Maybe this (https://github.com/pinterf/AviSynthPlus/blob/master/avs_core/filters/focus.cpp#L1148) sse2 part was a bit overoptimized, because now I replaced it with something I could understand and it is giving the same result as classic Avisynth 2.6.
I think using max thresholds (like QTGMC does) there is no problem with latest avs+ versions, I have put that special case in a separate optimized code path earlier.

So expect a fix for this.

And until then read this (http://www.vapoursynth.com/2016/09/blindly-copying-avisynth-considered-harmful/) comment from Myrsloik.

[Sharc]

.... So expect a fix for this.

And until then read this (http://www.vapoursynth.com/2016/09/blindly-copying-avisynth-considered-harmful/) comment from Myrsloik.
Excellent, thanks!
Well, maybe there exist better substitutes for temporalsoften(). I found it however to be a very useful and effective filter for VHS sources.

[MysteryX]

There is no SetMemory. I'm using x86.

The only thing that comes into the log is

INFO: LSMASHSource_LWLibavVideoSource() does not have any MT-mode specification.
Because it is a source filter, it will use MT_SERIALIZED instead of the default MT mode.

until it ran out of memory with 8 threads and crashed.

Here's the code, running on a 1080p source

file="Female President.mp4"
SetLogParams("log.txt", LOG_DEBUG)
LWLibavVideoSource(file, cache=False)
ConvertToYV12()
FrameRateConverter(60)
Prefetch(8)



FPS (min | max | average): 1.157 | 101672 | 13.12
Memory usage (phys | virt): 1446 | 1451 MiB
Thread count: 29
CPU usage (average): 52%

Output="flow"

FPS (min | max | average): 2.674 | 93538 | 18.11
Memory usage (phys | virt): 1423 | 1434 MiB
Thread count: 29
CPU usage (average): 64%


jm_fps alone

FPS (min | max | average): 3.096 | 97436 | 16.91
Memory usage (phys | virt): 1457 | 1465 MiB
Thread count: 29
CPU usage (average): 63%


I was wondering whether unused script filters were being initiated and causing performance or memory problems. I can see it's not an issue.

Yes, the issue is in MvTools2 and should be tested on jm_fps. In my case, I can't fix performance by increasing threads (8 cores). 12 gives a slight performance increase, and 16 gives a performance decrease.

and here's performance on a 1080p source with DCT=1 (preset="slow")

FPS (min | max | average): 0.083 | 83516 | 0.484
Memory usage (phys | virt): 1168 | 1166 MiB
Thread count: 26
CPU usage (average): 26%

I'd get a nice 1.5fps if CPU would work fully.

[chummy]

I'm facing a problem with specific source VP9 file with single keyframe. FFMS2 cause error and Directshowsource change clip duration by few millliseconds and cause framecount to change, this is enough to audio come out of sync.

[avisynth @ 0358ba40] FFVideoSource: Out of bounds frame requestede=16629.7kbits/s speed=0.247x
Unknown error occurred

Input check with FFMpeg:
Duration: 00:02:02.56, start: -0.007000, bitrate: 11360 kb/s
Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)

When feeding Avisynth+(ffms2) script to FFMpeg:
Duration: 00:02:02.12, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc

When feeding with Avs+ and Directshowsource:
Input #0, avisynth, from 'GTA5 1600mhz low.avs':
Duration: 00:02:02.59, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc

Directshowsource is only changing by 3ms, but for videos longer than 5 minutes there is noticeable out of sync audio.

Encoding the video directly with FFMpeg cause no such issue.

[MysteryX]

Under Avisynth 2.6, BitsPerComponent returns 0 instead of 8. Seems like a bug to me.

[Groucho2004]

Under Avisynth 2.6, BitsPerComponent returns 0 instead of 8. Seems like a bug to me.I checked your FramerateConverter git repository, the avisynth.h you're using does not have the fallback mechanism. Update to the latest headers and it will work correctly.

[hello_hello]

I'm facing a problem with specific source VP9 file with single keyframe. FFMS2 cause error and Directshowsource change clip duration by few millliseconds and cause framecount to change, this is enough to audio come out of sync.

I think DirectShowSource uses 29.970fps as the frame rate. Maybe adding AssumeFPS(3000,1001) to the end of the script will fix it, although the difference is very small.

There'd probably be minor differences in the way the timing is rounded, as at 29.970fps (3000/1001) each frame has a duration of 33.366666_ ms.
If my maths is correct your clip's duration should be 00:02:02.53.4666666 ms (at frame number 3658). I checked a clip with Avisynth using Info() and at frame 3658 it reports 00:02:02.55 ms. Maybe ffmpeg uses a slightly different pattern for rounding frames to the nearest ms.

Try this:
DirectShowSource("E:\video.mkv", audio=false, fps=29.970, convertfps=true).AssumeFPS(3000,1001)

Or this:
FFVideoSource("E:\video.mkv", threads=1, fpsnum=30000, fpsden=1001)

[stax76]

FFVideoSource fpsnum/fpsden drops/adds frame though

[sneaker_ger]

You guys realize a/v sync is about video and audio, right?

[MysteryX]

I've noticed the same with John Meyer's simpler script. It has to be one (or a combination) of the mvtools2 functions that does not scale well with MT.
I've just done an encoding test and it ran at about ~15% CPU usage which is unacceptable.

If I were to guess, it looks like incorrect mutex locks preventing proper MT execution.

[Groucho2004]

If I were to guess, it looks like incorrect mutex locks preventing proper MT execution.What mutex? Where?

[MysteryX]

What mutex? Where?
jm_fps has that issue, so in MvTools2. I haven't looked at the code.

[hello_hello]

FFVideoSource fpsnum/fpsden drops/adds frame though

So does convertfps=true for DirectShowSource, but if the frame rate is just a little off that might be enough to fix it (I've never understood why it isn't changefps=true for DirectShowSource, given it behaves the same ways as Avisynth's ChangeFPS).

chummy probably needs to add Info() to a script and preview the output to determine the frame rate and whether adding any sort of frame rate conversion would fix the audio sync.

Assuming that's actually the problem. We don't know how chummy is extracting/muxing the audio or whether it's being converted etc.

[Groucho2004]

jm_fps has that issue, so in MvTools2. I haven't looked at the code.MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose. SEt's AVS MT is even worse with this script.

Maybe the large temporal range and non-linear frame requests wreak havoc with the multi-threading.

[MysteryX]

MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose. SEt's AVS MT is even worse with this script.

Maybe the large temporal range and non-linear frame requests wreak havoc with the multi-threading.
What temporal range does it have? What's different in this plugin that could make it function worse than other filters?

Or is it requesting frames in the wrong order or something? Perhaps something is getting mixed up in the buffers or something.

[MysteryX]

MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose. SEt's AVS MT is even worse with this script.

Maybe the large temporal range and non-linear frame requests wreak havoc with the multi-threading.
SVP has the same temporal range as MvTools2 and performs extremely well, so it cannot explain the performance issues -- unless it requests them in a different order.

[Groucho2004]

SVP has the same temporal range as MvTools2 and performs extremely well, so it cannot explain the performance issues -- unless it requests them in a different order.Apples and oranges.

If you really want to find out run a profiler.

[MysteryX]

Here's an interesting case.


file="1080p.mp4"
LWLibavVideoSource(file, cache=False)
Spline36Resize(Width/2, Height/2)

FPS (min | max | average): 70.50 | 168.0 | 113.8
Memory usage (phys | virt): 108 | 105 MiB
Thread count: 21
CPU usage (average): 25%



file="1080p.mp4"
LWLibavVideoSource(file, cache=False)
Spline36Resize(Width/2, Height/2)
Prefetch(8)

FPS (min | max | average): 1.816 | 212585 | 42.70
Memory usage (phys | virt): 160 | 157 MiB
Thread count: 29
CPU usage (average): 67%
Adding Threads=1 to LWLibavVideoSource makes fps drop to 16


file="1080p.mp4"
LWLibavVideoSource(file, cache=False)
Spline36Resize(Width/2, Height/2)
jm_fps() # Without Recalculate
Prefetch(8)

FPS (min | max | average): 1.844 | 101671 | 77.29
Memory usage (phys | virt): 650 | 648 MiB
Thread count: 29
CPU usage (average): 71%
Going from 42.7 to 77.3 fps by adding jm_fps, really? This doesn't happen if we remove SplineResize.

replacing jm_fps with
FrameRateConverter(60, Output="Flow")

FPS (min | max | average): 3.539 | 129914 | 49.19
Memory usage (phys | virt): 956 | 955 MiB
Thread count: 29
CPU usage (average): 60%

FrameRateConverter(60)

FPS (min | max | average): 2.222 | 137555 | 33.69
Memory usage (phys | virt): 735 | 735 MiB
Thread count: 29
CPU usage (average): 42%

If I replace the source with ColorBarsHD, jm_fps with Recalculate runs at 75% CPU which isn't bad. FrameRateConverter runs at 54% CPU.

Here's the jm_fps function I'm using. Note: I did the test with super=superfilt line which isn't correct but that's how I ran the tests.

function jm_fps(clip C) {
Blksize=16
BlkSizeV=16
Dct=0
NewNum=60
NewDen=1
Recalculate = true
Prefilter = C.RemoveGrain(22)
superfilt = MSuper(prefilter, hpad=16, vpad=16) # all levels for MAnalyse
super = superfilt #MSuper(C, hpad=16, vpad=16, levels=1)
bak = MAnalyse(superfilt, isb=true, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, overlapv = BlkSizeV>4?(BlkSizeV/4+1)/2*2:0, search=3, dct=Dct)
fwd = MAnalyse(superfilt, isb=false, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, search=3, dct=Dct)
fwd = Recalculate ? MRecalculate(super, fwd, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : fwd
bak = Recalculate ? MRecalculate(super, bak, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : bak
Flow = MFlowFps(C, super, bak, fwd, num=NewNum, den=NewDen, blend=false, ml=200, mask=2, thSCD2=255)
return Flow
}

[Groucho2004]

MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose.I should mention that pinterf's latest mvtools2 still supports multi-threading through avstp.dll and that it is enabled by default (mt = true).
Adding avstp.dll to your plugin directory may improve things - or not.

[LigH]

Some time ago, I had issues with threading in complex functions (probably QTGMC?) and was recommended to remove avstp.dll from the auto-load directory, but that was with AviSynth 2.6 MT (SEt). Unfortunately, I do not remember the details of the circumstances, only the conclusion. Is the cooperation different under AviSynth+?

[Groucho2004]

Is the cooperation different under AviSynth+?Since AVS+ has a different multi-threading implementation I would say yes, it's different. If it's better or worse, I don't know.

Either way, I don't think it's a good idea to mix Avisynth's multi-threading with plugins that have internal MT. It's not only less efficient because of increased scheduling overhead, it also adds unnecessary complexity.

[LigH]

One reason why QTGMC exposes the parameter EDIThreads...

[MysteryX]

I should mention that pinterf's latest mvtools2 still supports multi-threading through avstp.dll and that it is enabled by default (mt = true).
Adding avstp.dll to your plugin directory may improve things - or not.
Which function(s) exposes mt parameter?

Perhaps if avstp.dll is using internal multi-threading and was never meant to be called several times, and it is being called multiple times, then the various threads lock each other.

[Groucho2004]

which function(s) exposes mt parameter?rtfm :)

[Groucho2004]

Perhaps if avstp.dll is using internal multi-threading and was never meant to be called several times, and it is being called multiple times, then the various threads lock each other.You should really read the documentation (https://forum.doom9.org/showthread.php?t=164407).

[MysteryX]

Adding and loading avstp.dll really doesn't change much at all -- and if it's not loaded, then I assume it's using single-threaded mode.

[postscripter]

Hello, guys. I've switched from AVS 2.6 to AVS+ and got my plugin broken. It can not even load the dll and says this:
---------------------------
VirtualDub Error
---------------------------
Avisynth open failure:
'D:/Личные папки/Projects/Ретранслятор/Osd/MyOSD.dll' cannot be used as a plugin for AviSynth.
(D:\Личные папки\Projects\Ретранслятор\Измерения\Скрипт.avs, line 29)
---------------------------

The plugin is C-plugin written in Delphi (forum.doom9.org/showthread.php?t=98327), and the classic AVS 2,5 - 2,6 had no problem with it.

The error I mentioned can be found on the line 534 (https://github.com/AviSynth/AviSynthPlus/blob/2d3cb6c011f520fc9433d6bff61a6d697cb09ecb/avs_core/core/PluginManager.cpp) and next on the 659. And the only check there is this:
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");
if (AvisynthCPluginInit == NULL) return false;

In russian we say that the dog is buried somewhere here, meaning the heart of the matter, which is close enough. As close, as the symbol [@], which is the dog in russian :) C-dlls usually have this @4 in export table after the name of the function, but delphi does not know about such things, and so do I. Google says, it's called function decoration. This is the first time I see such notation. Could anyone explain, what is it for and what to do with it? I can just recompile my plugin, of course, but wouldn't it be better to submit an issue (or the developers are already here)? Looks like a regression.

[Groucho2004]

Hello, guys. I've switched from AVS 2.6 to AVS+ and got my plugin broken.Avisynth+ does not support C/CPP 2.0 plugins.

[pinterf]

Yes, you are using probably the old, not supported interface.

The error I mentioned can be found on the line 534 (https://github.com/AviSynth/AviSynthPlus/blob/2d3cb6c011f520fc9433d6bff61a6d697cb09ecb/avs_core/core/PluginManager.cpp) and next on the 659. And the only check there is this:
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");
if (AvisynthCPluginInit == NULL) return false;

The same part in current version looks like this:
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L942

#ifdef _WIN64
AvisynthCPluginInitFunc AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init");
if (!AvisynthCPluginInit)
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init@4");
#else // _WIN32
AvisynthCPluginInitFunc AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init@4");
if (!AvisynthCPluginInit)
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");
#endif

[postscripter]

Avisynth+ does not support C/CPP 2.0 plugins.

Absolutely no idea what 2.0 means, but I've just changed the export name and have it usable now. Magic?

The same part in current version looks like this:

Well.. yeah. By the way. About current versions. Which one is the latest? Which is the latest for those, who need MT (http://forum.doom9.org/showthread.php?p=1666364#post1666364)? What happened with the original AviSynth repo (https://github.com/AviSynth/AviSynthPlus), which is referred by in Wiki (http://avisynth.nl/index.php/Main_Page)and on avs-plus.net (http://www.avs-plus.net/)? I can see the same contributors there and last activity in 2014'th... Did they lost the password?


looks like this
Looks the same for me) I see changes for 64 bit only. I reckon, you did it for Studio compiler, which introduce a big mess, adding @x for 32-bit DLLs only (https://stackoverflow.com/questions/28062446/x64-dll-export-function-names). But Delphi compiler does not add @x at all, unless you write it by yourself. Why don't you keep it simple, like this:
AvisynthCPluginInitFunc AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init");
if (!AvisynthCPluginInit) AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init");
if (!AvisynthCPluginInit) AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init@4");
if (!AvisynthCPluginInit) AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");

Or you can make an array of names))

[Groucho2004]

Absolutely no idea what 2.0 meansThe Avisynth C 2.0 API was the first C implementation by Kevin Atkinson. See here (https://forum.doom9.org/showthread.php?t=58840).

I've just changed the export name and have it usable now. Magic?Right now I don't have a reference table that lists the differences between the 2.0, 2.5 and 2.6 APIs but I suppose it's possible that just changing the export name might do the trick. Here's (http://avisynth.nl/index.php/Avisynth_Plugin_Development_in_C) some documentation but I'm not sure how helpful this is for your Delphi plugin thingy.

[Groucho2004]

Adding and loading avstp.dll really doesn't change much at all
It works better with something "simple" such as MDegrainN().

[qyot27]

Well.. yeah. By the way. About current versions. Which one is the latest? Which is the latest for those, who need MT (http://forum.doom9.org/showthread.php?p=1666364#post1666364)? What happened with the original AviSynth repo (https://github.com/AviSynth/AviSynthPlus), which is referred by in Wiki (http://avisynth.nl/index.php/Main_Page)and on avs-plus.net (http://www.avs-plus.net/)? I can see the same contributors there and last activity in 2014'th... Did they lost the password?
The MT branch is the most up-to-date on the upstream repo:
https://github.com/AviSynth/AviSynthPlus/commits/MT

The stuff pinterf is working on is currently being treated as an ad hoc development HEAD, there's an open pull request for it (https://github.com/AviSynth/AviSynthPlus/pull/101).

The reason MT hasn't been merged into the master branch has less to do with stability (to wit, you have to use builds from the MT branch if you want to use AviSynth+ with FFmpeg, since only the MT branch is synced up with AviSynth 2.6.0/2.6.1), and more to do with ultim going on hiatus every so often and wanting bugs that had existed in the MT branch to be resolved first. They mostly have*, but like I previously mentioned, hiatus. The same largely applies to pinterf's pull request, although the recent Unicode fixes broke GCC again.

*save for the problems inherent to synchronous access, as discussed at length over the last few pages of this thread.

Supported compilers are Visual Studio 2015 and higher, and GCC (experimental). I was in the middle of testing weird function decoration stuff with GCC and the C plugin back in April, but since I can only use 64-bit Wine or take a huge performance hit and run 64-bit Windows in a VM, that stalled out somewhat.

[pinterf]

New release with TemporalSoften fix.
Thanks to Sharc for the report (https://forum.doom9.org/showthread.php?p=1810075#post1810075).

Download Avisynth+ r2508-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2508-MT)

20170629 r2508
- Fix TemporalSoften: threshold < 255 (bug exists probably since r1576)

[Sharc]

New release with TemporalSoften fix.
Thanks to Sharc for the report (https://forum.doom9.org/showthread.php?p=1810075#post1810075).

Download Avisynth+ r2508-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2508-MT)

20170629 r2508
- Fix TemporalSoften: threshold < 255 (bug exists probably since r1576)
I confirm it's working now. Thank you.

[mkver]

Is it normal that using Levels with high-bitdepth input and enabled dithering eats incredibly much RAM? Is this a gigantic LUT?

Video = BlankClip(10000,pixel_type="YUV420P10")

Return Video.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
/*.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)*/

uses 82 MB. Each Levels that I uncomment adds about 64 MB to that. This does not happen without dither or with 8bit input.
On a related note: Would it be possible to add a switch to avsmeter to disable the "Script runtime is too short for meaningful measurements" error? I needed to increase the framecount of the blankclip

[MysteryX]

Is it normal that using Levels with high-bitdepth input and enabled dithering eats incredibly much RAM? Is this a gigantic LUT?
That's the reason LUT is disabled for 14-16 bit clips and it is using runtime evaluation.

[mkver]

That's the reason LUT is disabled for 14-16 bit clips and it is using runtime evaluation.
Are you sure about this? avsmeter reports exactly the same memory usage for 10, 12, 14 and 16 bits. And strangely: It doesn't matter if it is a greyscale format or what chroma subsampling it uses, the difference is negligible. I always thought that Levels treats Luma and Chroma differently (i.e. knows that luma should be scaled normally, but that chroma should be scaled from 128 so that one should need two LUTs for them).

[MysteryX]

Take a look at release notes of v2.2.2 (https://github.com/pinterf/masktools/releases/tag/2.2.2) and play with realtime argument.

When realtime is enabled is well documented here (http://avisynth.nl/index.php/MaskTools2)