Avisynth+

[tormento]

Render it out with some vfw lossless right in VDub like UTVide
It did its dirty job.

I hoped there was some glitch in AviSynth+ to fix about image import ;)

[TheFluff]

I see AviSynth+ is based on the memory allocation code of legacy AviSynth and should have the same problems as legacy AviSynth and AviSynth MT.

I'm pretty sure it's been substantially rewritten in the last few years but since I don't actually use it nor code on it I'll leave it to others to sort you out.

Also, how about you migrate to x64 to process your gigantic video frames without worrying about the antique memory limit?

[Groucho2004]

I wonder how much of the following statement still applies to to AVS+?
I ran the same script with SetMemoryMax(1500), no change in memory consumption or speed, no matter if AVS+ or classic 2.6.

[Motenai Yoda]

I ran the same script with SetMemoryMax(1500), no change in memory consumption or speed, no matter if AVS+ or classic 2.6.

classic 2.6 will crash if it go over 2GB (easy with many threads and some ram hugry stuff), avs+ can handle up to 3.5

[Groucho2004]

classic 2.6 will crash if it go over 2GB (easy with many threads and some ram hugry stuff), avs+ can handle up to 3.5Could you elaborate on "go over 2GB", "handle up to 3.5" and especially "many threads" with classic 2.6? Are you talking about SetMemoryMax()? 32 bit or 64 bit? Process memory available to Avisynth?

I can't decipher your statement.

[tormento]

Also, how about you migrate to x64 to process your gigantic video frames without worrying about the antique memory limit?

I am already on x64 encoding ambient. Never had idea of which value put there, if any use.

[Groucho2004]

I am already on x64 encoding ambient. Never had idea of which value put there, if any use.
I just found it odd that you put such a high value considering the low memory requirements of that particular script.
You may have to increase the default (512 MB) if you have a script with a large temporal range but you would test with small increments, 256 ~ 512.

[TheFluff]

I am already on x64 encoding ambient. Never had idea of which value put there, if any use.

I was talking to rean, who insists on 32-bit. No offense intended (to you).

[Groucho2004]

Also, how about you migrate to x64 to process your gigantic video frames without worrying about the antique memory limit?
---->
X64 build is not possible, because AviSynth includes assembler code that does not compatible with a x64 compiler.

[TheFluff]

Oh dear, such an insurmountable problem... I sure wish someone would do something about it.

[tormento]

I just found it odd that you put such a high value considering the low memory requirements of that particular script.

You may have to increase the default (512 MB) if you have a script with a large temporal range but you would test with small increments, 256 ~ 512.



It comes from my SMDegrain 6 frames span script + KNLMeans.

No idea of how AviSynth+ x64 deals with memory. I have plenty of it. I read that too much SetMemory could be negative too but it referred to old AviSynth. If any of the active devolver could clarify this aspect, would be very useful.

[shekh]

Tried to wrap VD filter through avs with avsplus-r1858-pfmod


Avisynth open failure:
rgb_levels has an invalid parameter string (bug in filter)


the script:

AviSource("E:\vd_dev\data\cfhd-high.avi")
LoadPlugin("E:\vd_dev\vd\VDubFilter.dll")
LoadVirtualdubplugin("E:\vd_dev\vd\plugins32\rgb_levels.vdf", "rgb_levels")


filter (nothing really special): https://sourceforge.net/projects/vdfiltermod/files/plugins/rgb%20levels/version%202/

arg_list from filter definition: "ddddddddd" (9 floats)

What`s wrong?

[ultim]

The memory and cache management in Avs+ is completely different from Avs 2.6. It has been redesigned and rewritten from scratch, though I was uncomfortably constrained by the existing API which resulted in half-assed code for memory reclamation in some (hopefully not too common) cases. Anyway, the caches in Avs+ are highly adaptive and self-learning, and do not use any caching hints like 2.6 in general to perform their jobs well. Also, as long as there is enough memory to satisfy all memory requests, even uncapped caches should not cause significant slowdowns, because caches will only grow if needed, not as long as there is free memory.

The default setting to SetMemoryMax() can be up to 1GB in Avs+, but may be lower depending on your amount of RAM. I know in earlier Avs 2.6 alpha/2.5 it was necessary to keep SetMemoryMax() low because if too high it resulted in funny caching behavior, leaving users with phenomena like slowdowns and/or unreasonably high memory usage. Avs+ should not suffer from anything like that, and SetMemoryMax() really just sets an (approximate) upper cap. If your script does not need that much memory though, a high upper limit (even if too high) does zero harm. In Avs+, the only use of constraining memory is to prevent paging. The justification is that often it is faster to recompute frames than to trash your rotational paging HDD (ofc if you have an SSD you'll have to reevaluate this claim). Another (similar) justification is, even if you had enough RAM, encodes often take many hours and sometimes even days, and if you want to keep using your computer in the background without hitting the paging limit, you might want to constrain the memory consumption of the encoding process.

But this is all TL;DR. The important takeaway is that in Avs+, a high SetMemoryMax() only hurts if otherwise your script causes excessive paging to a slow hard disk. Pro tipp: If you enable logging in Avs+, it will automatically notify you if you can speed up your script by setting your SetMemoryMax() higher ;) Edit: The optimal setting of SetMemoryMax() in Avs+ is anywhere in the range where it is higher than what your script wants to use, but lower than the value where it would cause paging. This range is often very broad, so only those will have trouble setting it who have either low RAM, or extremely hungry scripts. This is just a "rule of thumb" though, and its applicability will depend on your script and hardware.

[TheFluff]

Speaking of which, does Avs+ reuse framebuffers like the OG Avisynth does?

[ultim]

Speaking of which, does Avs+ reuse framebuffers like the OG Avisynth does?

Depends. Probably. Dunno what you mean exactly by "reuse".

[ultim]

I see AviSynth+ is based on the memory allocation code of legacy AviSynth...
Nope, not at all. See above.

[TheFluff]

Depends. Probably. Dunno what you mean exactly by "reuse".

(this is from memory, might be completely wrong)
OG Avisynth refcounted vfb's and when the refcount reached zero, instead of freeing the buffer it was kept around and a subsequent call to NewVideoFrame for a suitably sized frame could use that buffer instead of allocating a new one.

I'm asking because as far as I know VS didn't bother with this and I seem to remember Myrsloik stating that simple free/new malloc for "small buffers" worked "well enough". I'm curious how much the buffer reuse technique helps, especially for larger video frame sizes.

[ultim]

(this is from memory, might be completely wrong)
OG Avisynth refcounted vfb's and when the refcount reached zero, instead of freeing the buffer it was kept around and a subsequent call to NewVideoFrame for a suitably sized frame could use that buffer instead of allocating a new one.

I'm asking because as far as I know VS didn't bother with this and I seem to remember Myrsloik stating that simple free/new malloc for "small buffers" worked "well enough". I'm curious how much the buffer reuse technique helps, especially for larger video frame sizes.

Yes that technique is still there, and admittedly I intend to keep it around. Not because of some speed argument, but because it improves reliability. Simply put, it prevents memory fluctuation. It ensures that once Avs+ allocated a buffer, the same size can be allocated again after the previous instance is dereferenced. If Avs+ was to free each buffer whose refcount falls to zero, there'd be a chance that due to some other thread or application also allocating memory, Avisynth wouldn't be able to get a new buffer anymore, even though its total memory consumption didn't increase. This means without this technique there is a higher chance that your encode goes OutOfMemory in the middle, only because some other process or application thread had a sudden (maybe even temporary) memory spike.

[Groucho2004]

Yes that technique is still there, and admittedly I intend to keep it around. Not because of some speed argument, but because it improves reliability. Simply put, it prevents memory fluctuation. It ensures that once Avs+ allocated a buffer, the same size can be allocated again after the previous instance is dereferenced. If Avs+ was to free each buffer whose refcount falls to zero, there'd be a chance that due to some other thread or application also allocating memory, Avisynth wouldn't be able to get a new buffer anymore, even though its total memory consumption didn't increase. This means without this technique there is a higher chance that your encode goes OutOfMemory in the middle, only because some other process or application thread had a sudden (maybe even temporary) memory spike.
Thank you for that insight.

[bilditup1]

Moving from r1858_pfmod to r2172, I've been getting the following error when attempting to preview a fairly simply script in AvsPmod:
"Only a single prefetcher is allowed per script." (path_to_script.avs, line 13)
This is the script, which isn't particularly complex:

Import("C:\blu\MeGUI\tools\avisynth_plugin\reel.deel\mt_modes_latest.avsi")
LoadPlugin("C:\blu\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\jpsdr\x86\Release_Intel_W7_Core2_SSE4.2\nnedi3.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\RgTools.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\MaskTools2.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\pinterf\MvTools2.7.0.22d.dll")
Import("C:\blu\MeGUI\tools\avisynth_plugin\real_finder\QTGMC.avsi")
DGDecode_mpeg2source("d2v-path-here") # 1080i30 mpeg2 src
AssumeBFF()
QTGMC(Preset="Fast", ShowSettings=False)
Spline36Resize(1280,720)
Trim(0,3000)
Prefetch(4)

I checked the scripts I was importing - reel.deel's mt modes list and QTGMC - but Prefetch() is never called in them.
This error message must be a recent change, as in r2161, AvsPmod just crashes entirely, and when attempting to encode, the thread simply stalls and makes no progress (the same thing).
Removing the Prefetch call allows the script to be processed, in both r2161 and r2172, but I don't think mt is invoked, as it runs at st speeds (6.5fps vs 8.91).
I thought this was a problem with jpsdr's nnedi3, which I had to update to r25/r26 from r22 in order to avoid a memory violation with these new releases. But I reduced to script to merely this:

LoadPlugin("C:\blu\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("d2v-path-here") # 1080i30 mpeg2 src
Prefetch(4)

And still get the same error. Is this somehow a quirk of dgdecode? Is mt broken? Is it enabled differently now? Or is something else at work here?

ED: It is in fact DGDecode.dll. Using DGDecodeIM.dll and a dgi instead did not present this error - not only that but the encode goes some 50% faster (from 9 to 13.5 fps) than the original script did under r1858_pfmod and DGDecode (though the first time I tried it, it quit after one frame with a typical memory access error.)
Does anybody know what's going on with DGDecode? I guess it could be considered legacy software by now, and presume that maintaining compatibility with it probably is not a priority, but this strikes me as odd behavior all the same.

ED2: Part of the higher speed and memory access errors I had been experiencing appears to be because I had erroneously switched to using the XP compatible build of nnedi3. The W7_SSE4.2 build still goes faster than before but less dramatically (12fps instead of 13.5fps, and trying the XP build again just now I only managed to reach 12.6fps, weirdly), and you pay for it with the danger of a memory problem. I've also experienced what I believe are memory issues when using nnedi3 with jpsdr's ResampleMT (latest) - iow encode just stops in the middle but without quitting or throwing an error, just sticks at a certain frame - though not consistently: when it does work then it brings the speed back up to 13.5 even whilst using the W7_SSE4.2 builds of both it and nnedi3. (Will also post about it in jpsdr's threads, I suppose, if someone hasn't already pointed this out.)

ED3: Groucho2004's build of DGDecode has the same problem as neuron2's.

[ultim]

Moving from r1858_pfmod to r2172, I've been getting the following error when attempting to preview a fairly simply script in AvsPmod:
"Only a single prefetcher is allowed per script." (path_to_script.avs, line 13)

This should be a regression in Avs+ in the recent build. I'll take care of it by the weekend.

[bilditup1]

This should be a regression in Avs+ in the recent build. I'll take care of it by the weekend.

Wow, thanks for quick reply. Looking fwd to fix. Unfortch I've just discovered that TDecimate does not work with MT enabled, whether using tritical's original TIVTC.dll or groucho2004's build. Works fine in r1858_pfmod, quits with "internal error during prebuffering!" in r2085, r2161, r2172.

[tormento]

The default setting to SetMemoryMax() can be up to 1GB in Avs+
So, having 16+ GB of RAM and a x64 environment, which is the maximum value we can set?

Is it of any use or we can write scripts without allocating memory?

[Groucho2004]

I've been getting the following error when attempting to preview a fairly simply script in AvsPmod:
...
This is the script, which isn't particularly complex:

Import("C:\blu\MeGUI\tools\avisynth_plugin\reel.deel\mt_modes_latest.avsi")
LoadPlugin("C:\blu\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\jpsdr\x86\Release_Intel_W7_Core2_SSE4.2\nnedi3.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\RgTools.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\MaskTools2.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\pinterf\MvTools2.7.0.22d.dll")
Import("C:\blu\MeGUI\tools\avisynth_plugin\real_finder\QTGMC.avsi")
DGDecode_mpeg2source("d2v-path-here") # 1080i30 mpeg2 src
AssumeBFF()
QTGMC(Preset="Fast", ShowSettings=False)
Spline36Resize(1280,720)
Trim(0,3000)
Prefetch(4)

The script is far from simple, have a look at the content of qtgmc.avsi. As for your stability problems (aside from a AVS+ issue), see also here (http://forum.doom9.org/showthread.php?p=1779384#post1779384).

[shekh]

Tried to wrap VD filter through avs with avsplus-r1858-pfmod

Avisynth open failure:
rgb_levels has an invalid parameter string (bug in filter)
...


same with 2172

[burfadel]

Ultim, I hope I wasn't 'out-of-line' PM'ing you earlier with the script sample, I just wanted to avoid stoking the fire of the other threads regarding upsampling, changing resolutions etc., seeing as the script did involve some manipulation in that regard. I hope that it does prove useful though in what I mentioend regarding single thread and multithreaded modes etc, and also how it can run quite fast.

Is my assumption wrong in that any script either becomes all multithreaded on the avisynth side, even with MT mode 3 on the plugins, or single threaded on the Avisynth side when prefetch is not stated, but still multithreaded invidividual plugins if the plugins are multithreaded? If the former isn't right, it does seem to exhibit that behaviour.

[bilditup1]

The script is far from simple, have a look at the content of qtgmc.avsi.

Yes, I'm aware that QTGMC itself is complex. I meant that my snippet was legible, straightforward and didn't have much of my own more-likely-to-be-faulty logic in it. In any case, QTGMC's presence was ultimately irrelevant.

[Wilbert]

https://mega.nz/#!dxowVRCR!j5OaMcXwt3s174UHjVKcOfB-Y4DfcRXapah-UKQJlP0
What Groucho2004 said. You have to be patience. I imported your script in Virtualdub and compressed it to Xvid but it took me 10 hours on my slow laptop (2.2 GHz). I used plain AviSynth though, but that probably doesn't matter. Btw, it consists of 324 images (iirc).

[Groucho2004]

Btw, it consists of 324 images (iirc).Should be 434 (http://forum.doom9.org/showthread.php?p=1779098#post1779098).

[qyot27]

There is nothing ordinary about a nearly CD sized animated gif.
I've noticed this happening on image hosting sites that offer a gif version and a webm version of whatever the animated image sequence is. The gifs in those cases are sometimes outlandishly sized, because I assume what's going on is the image host offers the ability to upload video, so the user uploads a video file, and then the image host compresses it to webm and to gif. But the gif's resolution hasn't been reduced, so you end up with ridiculous 1920x1080 animated gifs alongside a smaller, higher quality normal video file.

I keep asking myself what the use case of that could possibly be vs just using a video host, but I've never come up with a satisfactory answer. Because even meme sites like these gif posts probably are intended for should really have no issues embedding video files in 2016, and if your computer is so old that it can't decode one of those VP8 or VP9 webm files, is your browser going to somehow not choke on a 1080p gif?

[Wilbert]

Should be 434 (http://forum.doom9.org/showthread.php?p=1779098#post1779098).
Yup, my encoding has 434 frames. Should have checked before recalling from my bad memory ;)

[gaak]

Hi,

In trying AVISynth+ r2085 i386 in MT mode with this script on a 1080p source:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSource", 3)
LoadPlugin("C:\MKVideo Encoder NV\DGDecNV\DGDecodeNV.dll")
DGSource("C:\MKVideo Files\Input_Video_File.dgi")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=1.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)
src=last
dr=src.RemoveGrain(4, 2)
src.HQDeringmod(dr, drrep=13, sharp=1, thr=14.0, darkthr=0, Y=3, U=3, V=3)
return(last)
Prefetch(8)

I get the same results (about 6 fps on an i7 930) if I run in single thread mode. What am I doing wrong?

[Groucho2004]

Hi,

In trying AVISynth+ r2085 i386 in MT mode with this script on a 1080p source:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSource", 3)
LoadPlugin("C:\MKVideo Encoder NV\DGDecNV\DGDecodeNV.dll")
DGSource("C:\MKVideo Files\Input_Video_File.dgi")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=1.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)
src=last
dr=src.RemoveGrain(4, 2)
src.HQDeringmod(dr, drrep=13, sharp=1, thr=14.0, darkthr=0, Y=3, U=3, V=3)
return(last)
Prefetch(8)

I get the same results (about 6 fps on an i7 930) if I run in single thread mode. What am I doing wrong?
Remove "return last" or move it to the end of the script. Prefetch never gets called.

[gaak]

Remove "return last" or move it to the end of the script. Prefetch never gets called.

Thanks!

[Groucho2004]

I imported your script in Virtualdub and compressed it to Xvid but it took me 10 hours on my slow laptop (2.2 GHz).I just tried the same with Xvid 1.22 and it took 30 seconds. Even on my really ancient laptop it takes only 2 or 3 minutes. Your 10 hours are bizarre.

[Groucho2004]

Min. installer (w/o MS runtimes) for the latest build (r2172) (https://www.dropbox.com/s/aqlcgzdsh76akki/AviSynth%2B%20r2172.7z?dl=0)
Latest All-In-One runtimes (if needed) (http://repacks.net/forum/viewtopic.php?f=6&t=125)

[Wilbert]

Which doesn't conform to suggestion of Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx) because this are different formats that can't be directly mapped to current AV_PIX_FMT_*s.
Some news. The layout of this P010 format is planar luma with packed chroma (see description in the link above, i missed that earlier on). It is actually supported in ffmpeg with the flag AV_PIX_FMT_P010LE:

P010 is the 10-bit variant of NV12 (planar luma, packed chroma), using two bytes per component to store 10-bit data plus 6-bit zeroes in the LSBs.
See https://patches.libav.org/patch/60979/ and https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L2015. There is no 12/14 bit analog of this format. So it makes sense not to use that in AviSynth.

[qyot27]

Some news. The layout of this P010 format is planar luma with packed chroma (see description in the link above, i missed that earlier on). It is actually supported in ffmpeg with the flag AV_PIX_FMT_P010LE:


See https://patches.libav.org/patch/60979/ and https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L2015. There is no 12/14 bit analog of this format. So it makes sense not to use that in AviSynth.
Huh? We're not using P010, so the lack of 12- or 14- bit variants of it doesn't matter. The 10-bit formats we're using are the all-planar ones: YUV(A)***P10, GBR(A)P10. Or YUV(A)***P12/14, GBR(A)P12/14, respectively. To my understanding, P010 is mostly a format used by graphics cards and screen output types of jobs, not one that should be getting used for practically anything else. It's like NV12/NV21.

And the patch to add the new pix_fmts to FFmpeg's AviSynth demuxer was already committed close to a week ago. (http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avisynth.c;h=1fe8e083be552f2d3efcce6821d0982f6a5ae3d7;hp=04ac2576cc68c14e31d9a8f114aff7490e4719f4;hb=92916e8542e425ca20daddb490261a5818643206;hpb=ac028794ad702375c27143bd86d459534ef6fc2f) The planar RGB formats and ConvertTo16bit's 10/12/14 conversions don't quite work yet; you need the pull request that pinterf is currently working on (https://github.com/AviSynth/AviSynthPlus/pull/101) for those to be fixed on our side, plus another patch that's on the FFmpeg-devel mailing list (http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198570.html) to make sure the Planar RGB formats are output correctly.

Zeranoe's FFmpeg-git builds (https://ffmpeg.zeranoe.com/builds/) should work with them just fine now, with the caveats I mentioned above. However, you can get proper 10/12/14 YUV output if you use f3kdb or Dither to scale them up and then ConvertFromDoubleWidth/Stacked. The alpha-enabled formats and Planar RGB were a deeper issue that had to be resolved by exposing them through the C interface first (r2172 doesn't do that yet, that's why the pull request's changes are needed).

[Wilbert]

Huh? We're not using P010, so the lack of 12- or 14- bit variants of it doesn't matter. The 10-bit formats we're using are the all-planar ones: YUV(A)***P10, GBR(A)P10. Or YUV(A)***P12/14, GBR(A)P12/14, respectively. To my understanding, P010 is mostly a format used by graphics cards and screen output types of jobs, not one that should be getting used for practically anything else. It's like NV12/NV21.
I know you are not using P010. I was explaining to MasterNobody why it is not used. At first i thought (and i guess MasterNobody too) that the only difference was the location of the zero padding, but as you repeated the chroma is packed too in P010.

[pinterf]

Hi, just a short project report on the high bit depth part.

Probably you know, that instead of the the original plans (YUV 16 bit/float 4:2:0, 4:2:2 and 4:4:4) we finally decided to support more formats.

Avisynth core got support (at least on my workbench) for
- YUV 10-12-14 bits (and of course the 16 bit and float format)
- RGB48 and 64 (RGB24 and RGB32 16-bit counterparts)
- Planar RGB and Planar RGBA (8-10-12-14-16 bit integers and float)
- YUVA (YUV with a 4th alpha channel) with the same options as YUV.

Most of the filters and functions are ported and support all these new formats.

Not much left
- Invert
- Overlay and Mask filters (all)
- SkewRows (not priority)
- GeneralConvolution for RGB32

And there are planned refinements.
- There should be only one bitdepth converting function, instead of existing ConvertTo8bit/16bit/Float
- Dithering for 8/10 bit conversion
- more functions to use SIMD (SSE2)

Some filters that are working with lookup tables internally (Limits, RGBAdjust) are not available for float video formats.

10-14 bit formats are mainly for export/import, but a few filter can already use them natively (Limits, RGBAdjust, text-overlay, etc)

That's all for now, the work is going on...

[Groucho2004]

This applies only to AVS+ 64 bit. Test release: r2172

Script:
colorbars(width = 1280, height = 720, pixel_type = "yv12").killaudio().assumefps(50, 1)
Dummy()

"Dummy()" is my test plugin that simply triggers a 0xC0000094 / STATUS_INTEGER_DIVIDE_BY_ZERO exception, download here (https://www.dropbox.com/s/slusj7lrfddmxcr/Dummy64.7z?dl=0)

AVSMeter reports the correct module:
AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004
AviSynth+ 0.1 (r2172, MT, x86_64) (0.1.0.0)

Exception 0xC0000094 [STATUS_INTEGER_DIVIDE_BY_ZERO]
Module: E:\Apps\VideoTools\AVSPlugins\AutoLoad64\Dummy64.dll
Address: 0x0000000004CE14A5
However, if I put "Prefetch(x)" at the end of the script, this is the result:
AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004
AviSynth+ 0.1 (r2172, MT, x86_64) (0.1.0.0)

Exception 0xC0000094 [STATUS_INTEGER_DIVIDE_BY_ZERO]
Module: D:\WINNT\system32\kernel32.dll
Address: 0x0000000077D67DDD

[LigH]

May be interesting in which system function. Possibly in a threading management routine? That may require a detailed crash dump with stack trace.

[Groucho2004]

May be interesting in which system function. Possibly in a threading management routine? That may require a detailed crash dump with stack trace.
Well, AVSMeter catches the exception so there is no crash dump. :D
I'll try with MPC-HC.

Edit: MPC-HC crash dump (http://pastebin.com/QYfg7JXS)

[LigH]

You might add the *.pdb file for access to symbols ... but the appearance of "ntdll!NtWaitForMultipleObjects" and "kernel32!ReleaseSemaphore" in the stack trace seem to support my suspicion that the thread scheduling gets disturbed by the exception. Yet, I am no expert, so no warranties... :o

[qyot27]

A couple previous posts of mine getting clarified:
I have some weird results with the MinGW builds. None of them - a cross-compiled AviSynth+ built under Ubuntu with MinGW-w64 4.0.6 and GCC 6.1.0, one built under msys2 with GCC 5.4.0 (I don't know which MinGW-w64 version), or the build ultim provided above - works with FFmpeg. However, the msys2 build and ultim's do at least have FFmpeg error out the same way it does if the proper MSVC runtime can't be found, while the one built on 6.1.0 just up and crashes.

I think part of it might have to do with function decorations. Or compiler optimizations that I tried enabling on the 6.1.0 build. It'll get worked out eventually.
This was almost certainly the capi.h issue MasterNobody brought up. (http://forum.doom9.org/showthread.php?p=1777515#post1777515)

I attempted it from a different angle, and that's if the ifdef was changed to accept MSVC OR MINGW, then the MinGW-GCC build of AviSynth+ with that change and the build of Libav depending on that header were suddenly okay (so long as I kept the autoload folders empty of .dlls).

Unfortunately, the MinGW-GCC build of FFMS2's C plugin did not work, likely because it was using a much older version of the header. So C plugins will probably need to update against it to work right as well. Whether they'll remain backward compatible with AviSynth 2.6 in that case, I don't know. I also didn't test MSVC builds against the expanded ifdef, so those might still fail to work.

All that to say, it's encouraging that a program that uses the C interface to talk to AviSynth can indeed use MinGW-GCC builds of AviSynth+. It's still early in fleshing out the support there (since there's bound to be conflicts to hammer out), but at least there's confirmation that one configuration of it actually works.

Also, it would appear that VS2015 builds work with Wine 1.9.17 now, if msvcp140.dll is specifically overridden to native,builtin in winecfg and the VS2015 redist is installed. The only issue is, that version of Wine is still -devel, so it may not be a good idea yet to rely on (and if we want a 'just works' solution there before dropping VS2013, it probably shouldn't require overrides or installing the redist package).
I spoke a bit too soon on this. 32-bit builds work as I described there, but Wine 1.9.x is still not compatible with the 64-bit builds, even if you've installed the 64-bit VS2015 redist.

[Motenai Yoda]

mergechroma and rgbadjust are bugged only for me?

[pinterf]

mergechroma and rgbadjust are bugged only for me?

Last week I was working on porting RgbAdjust to RGB48/64 and planar RGB 8-16 bit formats and found a bug, that would cause buffer overflow when creating the lookup table.
If you specify dither=true, it should not occur.

What is the problem with MergeChroma?

[Motenai Yoda]

Last week I was working on porting RgbAdjust to RGB48/64 and planar RGB 8-16 bit formats and found a bug, that would cause buffer overflow when creating the lookup table.
If you specify dither=true, it should not occur.
thanks
What is the problem with MergeChroma?
the weight part on yv12

[StainlessS]

Possibly connected to AVS Standard MergeChroma problem, here:- http://forum.doom9.org/showthread.php?p=1504231#post1504231
Was originally
MergeChroma (clip1, clip2, float Chromaweight=1.0)
IanB Added Alias
MergeChroma (clip1, clip2, float weight=1.0)

Perhaps it did not make it into AVS+

EDIT: And MergeLuma used LumaWeight, also added the Weight alias. [EDIT: About v2.6 Alpha 3, period].

EDIT: @ Motenai Yoda Below post:
OK, I think you just added the stuff in blue, the weight part on yv12.

[Motenai Yoda]

@StainlessS doesn't seems the same issue
http://1.t.imgbox.com/h6HLHoeR.jpg (http://imgbox.com/h6HLHoeR)