Avisynth+

[MysteryX]

Thanks!! This newer version finally works fine with SVP.

[ryrynz]

I guess I'll look at this again once another phase of development has occurred, hopefully some time next year.

'Kay well I gave 1847 a shot but it just crashes MPC_BE x86 (build 1417) instantly with exception code 0xc0000005 when passed through ffdshow (4533) Even with nothing in the Avisynth field it still happens. No problems with Avisynth-MT.

[jpsdr]

@pinterf
First, thanks for your work, i think a lot of people appreciate what you did, even if they stay silent.

And...
Do you think, by any chance, you can take a look at this issue, if it can be fixed ?
You can see the whole thread here (https://www.neatvideo.com/nvforum/viewtopic.php?t=1127), but the most important point is this information :

It seems that the x64 version of Avisynth has a different size of the CScriptValue structure that is used to pass arguments to a filter (as compared with the 64-bit VirtualDub). This makes NeatVideo crash when processing the preset name (the second argument of NeatVideo4). The size difference may be a bug in Avisynth x64.


Anyway, thanks again for your work.

[pinterf]

'Kay well I gave 1847 a shot but it just crashes MPC_BE x86 (build 1417) instantly with exception code 0xc0000005 when passed through ffdshow (4533) Even with nothing in the Avisynth field it still happens. No problems with Avisynth-MT.
Perhaps missing VS2015 redistributable?

[pinterf]

@pinterf
Do you think, by any chance, you can take a look at this issue, if it can be fixed ?
You can see the whole thread here (https://www.neatvideo.com/nvforum/viewtopic.php?t=1127), but the most important point is this information :

Anyway, thanks again for your work.
So charting unknown seas :). Feedback is always welcome, anyway. I'll look into it.
And thank you, I like silence only when it means that things are working fine.

[ryrynz]

Perhaps missing VS2015 redistributable?

Yup. Thanks, it's working well in comparison to MT so far.

[pinterf]

@jpsdr
(vdub) Found something. Who can test it? I don't want to circulate an interim test build in public.

[jpsdr]

PM me a link. Don't need XP build for this test, but need both 32 and 64 bits dll.

[MysteryX]

So charting unknown seas :). Feedback is always welcome, anyway. I'll look into it.
And thank you, I like silence only when it means that things are working fine.
Thank you so much. There's a LOT of people who have been waiting a LONG time for someone to make a MT version of AviSynth+ that works fine, and it's been dead for so long.

Finally someone who puts his butt into use.

I'll do some testing of replacing AVS 2.6 with this version for encoding and let you know how it goes. The previous version wasn't working with all filters.

According to my first tests, however, it seems that L-MASHSOURCE lags on some videos, even when CPU isn't fully used, whereas with 2.6 it worked fine. This would require more testing to see where that's coming from.

[Stereodude]

Does it actually work? I gave up on MT Avisynth a long time ago. I couldn't get satisfactory results no matter how I tweaked the settings for FHD material. It would crash well before you could encode an entire ~2 hour movie with it. I had much better luck using MP_Pipeline to separate different high CPU usage filters into their own threads. Using MP_Pipeline and splitting the source across several simultaneous lossless intermediate files (usually 4) that were joined and then encoded worked best for me.

IE: If I have a 100,000 frame source, I generate a lossless intermediate file from 0-25010, another from 24990-50010, another from 49990-75010, and another from 74990-100000. I would do that with four simultaneous Virtualdub jobs each generating an AVI file. Trim the overlap areas in an AVIsynth and use that to do my 2 pass x264 encode.

[MysteryX]

For me AviSynth 2.6 MT has been working well. Perhaps there are a few filters that are more unstable with MT but those I use were working well. This AviSynth+ appears to be very stable so I'm sure it will work fine although I have to try first. The previous version of AviSynth+ MT wasn't working with some filters such as NNEDI3.

[StainlessS]

Stereodude,

You are recommending Overlap again despite your acceptance that it is unnecessary, here (final edit):- http://forum.doom9.org/showthread.php?p=1714239#post1714239

EDIT: Edit: Now I see what you're saying to do. Trim the output not the input and run those scripts in parallel.

You can Trim at END of script and overlap is NOT necessary.

EDIT: The "MakeMultiPartScripts.avs" script given earlier in that thread generates multi-part scripts
to avoid making mistakes in your Trim frame numbers. [EDIT: Post #15 in that thread]

[mark0077]

Hi, I tried avisynth+ a few times in the past and have just put together a new PC and am wondering is it worth using it for SVP usage performance wise or not now with the latest versions? If theres a significant performance difference I will look at the steps to get SVP working with avisynth+ instead of Sets MT version of avisynth.

[Stereodude]

Stereodude,

You are recommending Overlap again despite your acceptance that it is unnecessary, here (final edit):- http://forum.doom9.org/showthread.php?p=1714239#post1714239

EDIT:

You can Trim at END of script and overlap is NOT necessary.

EDIT: The "MakeMultiPartScripts.avs" script given earlier in that thread generates multi-part scripts
to avoid making mistakes in your Trim frame numbers. [EDIT: Post #15 in that thread]
I was saying what I've done in the past. Frankly, I'd forgotten about our prior conversation. I haven't done one of these since our back and forth, but I'm glad you're following me around the forum remembering everything I've posted in the past to correct me. This way when I do one in the near future it'll be fresh in my memory. Especially now that I have systems with 8 and 16 physical core Xeon CPUs (with HT) and parallelism is going to be even more important.

[StainlessS]

Yep, I keep a close track on all of your posts just so I can do a little nit picking :)

Nah, I was gonna point out that thread and discovered (to my joy and delight) that it was you who was on the other end
of conversation, hehe.

My previous favorite similar lil ol correction was in this post:- http://forum.doom9.org/showthread.php?p=1729222#post1729222

EDIT: In response to fvisagie.

[MysteryX]

Hi, I tried avisynth+ a few times in the past and have just put together a new PC and am wondering is it worth using it for SVP usage performance wise or not now with the latest versions? If theres a significant performance difference I will look at the steps to get SVP working with avisynth+ instead of Sets MT version of avisynth.
For AviSynth+ and SVP, view this thread
http://www.svp-team.com/forum/viewtopic.php?id=3270

I find it to be the fastest and most stable so far. Memory usage is TWICE LOWER.

As for the videos that would lag with L-SMASH Source, playing with the threads fixes it. In fact, I am now able to use LWLibavVideoSource for real-time playback without using MT. MT wasn't recommended for this plugin but it was the only way to prevent lag according to my test. With AviSynth+, no MT works perfect :) So far. I'll have to try with a wider variety of videos.

[Sparktank]

For AviSynth+ and SVP, view this thread
http://www.svp-team.com/forum/viewtopic.php?id=3270

I find it to be the fastest and most stable so far. Memory usage is TWICE LOWER.

This is exciting news!

I'll have to dedicate some time to getting AVS+ set up again (Groucho's switcharoo setup).

I'm currently still using 260_MT to play.
I remember liking old AVS+ for awhile, but for non-SVP things, it was naturally unstable to use in AvsPmod (even with updates to APM).

[pinterf]

Do not fear of MT mode and use 64 bit, there may be more x64 filters than you would think before!

If you have enough memory, don't limit your script using it, even if avs+ occupies much less memory footprint than at the beginnings.

You can test the peak memory need with SetMemoryMax(bigvalue) and watch AvsMeter/AvsMeter64.

As for MT, set default mt mode to 2, for source filters 3, Prefetch(8) then rock'n'roll.

OK, fps-wise on my i7 processor Prefetch(7) or Prefetch(8) is not scaling well compared to Prefetch(6), but is still faster a bit.

This night an AVS+ x64 with SetMemoryMax(6000), UHD (3840x2160) colorbars + QTGMC(Fast) + Prefetch(8) is trying to kill my PC in the office.
(Fast i7 with 8G RAM, now it's at more than 4 fps and is working hard at 80% CPU since 3 hours).

Wondering, at what memory consumption would this UHD source script stabilize itself if I didn't put that 6G limit. So, which volunteer has 24G RAM? :) That should be more than enough for the test I think.

[ryrynz]

I find it to be the fastest and most stable so far. Memory usage is TWICE LOWER.


Yeah memory usage is a lot lower, I used to have a max mem set of 500MB with MT and my usage is almost 500MB lower using AVS+.

As CPU usage goes it's very close for me just using a couple of filters, the dynamic CPU clock almost looked to be a touch lower.
Might be time to finally give 64 bit a go.

Gave it a shot and get instant crashes on playback. Replaced AVS+ with the 64 bit version, ffdshow 64 bit, MPC-BE 64 bit with the 64 bit VS2015 redistributable installed also.
Removed all filters and it still crashes.

[pinterf]

Ok. So at least one component needs polishing. It is 2016 now, 64 bit things should work*. We can exclude the redistributables :) Remains: avs+, a remaining filter, source filter, mpc, ffdshow, interaction between them

*or let's be sarcastic: it's 2016 now, higher than 8 bit color spaces should be supported natively in the whole workflow.... er ...not for current avisynth. But we should think about it seriously. Opinions? Biggest obstacles? I know there is VapourSynth with plenty of high-bit-depth filters, but I'd like to have spare batteries also :)

[qyot27]

I'm going to place the blame firmly on ffdshow there. AviSynth+ 64-bit is known to work with 64-bit builds of ffmpeg from after March 2013, or by extension, things that link against the libavformat from those builds of ffmpeg, like LAV Filters or mpv; that does not include ffdshow. And if ffmpeg fails, only then would that point to one of the filters being the problem.

[qyot27]

*or let's be sarcastic: it's 2016 now, higher than 8 bit color spaces should be supported natively in the whole workflow.... er ...not for current avisynth. But we should think about it seriously. Opinions? Biggest obstacles? I know there is VapourSynth with plenty of high-bit-depth filters, but I'd like to have spare batteries also :)
ultim mentioned some time back that it wouldn't be *that* difficult to fix the >8bit support in the core, more that it would be tedious.

Personally, I'd urge us to get cross-platform support working first, because it means more ready-to-deploy testing environments so those that are willing to do the tedious work can have fast turnaround testing times. More eyes and potential contributors overall.

[pinterf]

What is missing for cross platformity? I guess the first step that the project could be compiled with GCC?

As for the high bit depth: yes, I already looked into the core for possible 8bit+ usage too, and mostly its a mechanic work. Luts will be ugly, for some filters templates could be used. At least for C implementation because intrinsics need to be optimized for distinct color depths. Then there will be theoretical problems with colors, primaries, gamma, why we use 16-235 or its 16 bit counterpart when cameras are using 16-255 and happily ignore the so called standards etc.

[MysteryX]

AVS+ might be a little bit more stable than AVS 2.6 but it still has random crashes and freezes, which is noticeable when playing videos with SVP and seeking. It would be nice if we could get the bugs sorted out in the standrad AVS before implementing other major features that will add complexity and may add to the instability. When small bugs are left out, they accumulate until they become unmanageable.

Edit: I just saw a comment that this freeze may be in ffdshow and not related to AviSynth

[chainik_svp]

64-bit ffdshow + AVS+ 1847 actually works.


09:51:34.322 [I]: VideoPlayer: new ffdshow video [405c2] in unknown player (64-bit) [MPC-BE x64 1.4.3.5182] on screen 0
09:51:34.556 [I]: Playback [405c2]: Frame server (64-bit) 0.1.0.0, AviSynth+ 0.1 (r1847, MT-pfmod, x86_64), C:\Program Files\MPC-BE x64\avisynth.dll


If it crashes on start I can suggest to double-check all the dependencies (with the Dependeny Walker) for the given avisynth.dll

[pinterf]

My poor PC has successfully finished a nightly UHD stress-test
HW: i7-3770@3.4GHz, 8G RAM, Win7 Prof x64


AVSMeter 2.1.6 (x64)
AviSynth+ 0.1 (r1847, MT-pfmod, x86_64) (0.1.0.0)

Number of frames: 215784
Length (hh:mm:ss.ms): 01:11:55.680
Frame width: 3840
Frame height: 2160
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 215784 (0 - 215783)
FPS (min | max | average): 0.285 | 331285 | 4.601
Memory usage (phys | virt): 5851 | 6260 MB
Thread count: 90
CPU usage (average): 83%

Time (elapsed): 13:01:41.985

script:

SetFilterMTMode("DEFAULT_MT_MODE",2)
SetMemoryMax(6000)
colorbars(width = 3840, height = 2160, pixel_type = "yv12", staticframes=false).killaudio().assumefps(25, 1)
AssumeBFF()
QTGMC(Preset="Fast")
PreFetch(8)


used modules:
- QTGMC 3.33
- mvtools2 2.7.0.1 - my mod based on 2.6.0.5 https://github.com/pinterf/mvtools/releases
- nnedi3 (SSE4.2 build) - JPSDR v0.9.4.20 (05/09/2015) https://github.com/jpsdr/NNEDI3/releases
- masktools2 (12/20/2013) https://github.com/tp7/masktools
- rgtools (02/02/2014) https://github.com/tp7/RgTools/releases

[chainik_svp]

can I suggest to build it with VS 2013?
otherwise it becomes tricky to install this on some client machine:
1. install AVS+ using official installer (which will install VC++ 2013)
2. install VC++ 2015
3. replace the dll

[pinterf]

I suppose once the version deserves, there will be a new installer package.
At the beginning I spent three days with reinstalling VC++ things to have VS versions simultaniously side-by-side (in theory it works, for me not), I don't want back those times. Updating one made the other unusable. Even the last VS2015 update 2 killed itself (splashscreen flashed then nothing happens) and had to iterate between uninstall something/repair/restart machine loops.

[ryrynz]

AVS+ might be a little bit more stable than AVS 2.6 but it still has random crashes and freezes, which is noticeable when playing videos with SVP and seeking. It would be nice if we could get the bugs sorted out in the standrad AVS before implementing other major features that will add complexity and may add to the instability. When small bugs are left out, they accumulate until they become unmanageable.

Edit: I just saw a comment that this freeze may be in ffdshow and not related to AviSynth

This. If pinterf or anyone else could fix this issue it would be a god send. As he said, it sucks having to run 32 bit programs just to get Avisynth running in real time.
Surely it can't be any more difficult than what was done recently to fix the performance issues with AVS+.

64-bit ffdshow + AVS+ 1847 actually works.

If it crashes on start I can suggest to double-check all the dependencies (with the Dependency Walker) for the given avisynth.dll

I'll take a look.

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

First time using this app, so here's a link (http://www.filedropper.com/avisynth) to the dwi, would appreciate if someone could tell me what's possibly causing the crash, cheers.

[MysteryX]

I believe there are many able and willing to provide great feedback for improvements and testing, but few will go into the AviSynth+ source code itself.

If pinterf is willing to work on this until we get a great stable official version, then we can do our part to test and fix most of the bugs that are left.

I think that polishing the current version is more important than implementing big new features such as increased colorspace. Once an official stable version is released, then looking into additional features could be the next step.

This certainly encourages me to get back into testing scripts and code with this new version.

[MysteryX]

As for the random crashes, I was using AviSynth 2.6 MT *and* AviSynth+ (non-MT) with my software. For previews, I found AviSynth+ to be the most stable but it would still crash sometimes. AviSynth 2.6 MT is the version that provided the best performance for actual encoding.

This wasn't using ffdshow so we can put that out of the equation in this case.

[pinterf]

If it is reproducible, it can be caught.
Can you provide the steps to reproduce?
From the beginnings if possible, e.g. download this and that, open xy type media file, click here and there, etc...

[MysteryX]

Absolutely RANDOM!!

Good luck :)

[LigH]

The more random, the more probably the reason may be hardware related...

[Groucho2004]

The more random, the more probably the reason may be hardware related...
Maybe. However, a scenario with Avisynth/QTGMC()/[encoder] is very complex and seemingly random events are reproducible if one uses strict and systematic testing procedures. Just using a different version of a filter can easily change the result.

[pinterf]

Absolutely RANDOM!!

Good luck :)
Bad answer :)

Random =>
Occurs in X minutes
or Y times you start the program
or seek the video back and forth =>
Crash =>
We can catch it =>
Fix it =>
Happier world

No steps to reproduce =>
No crash =>
No Problem

So what did you do with which software on what video before the random things appear?

[pinterf]

Random things. TemporalSoften memory leak occured after the 35000th frame in the QTGMC process. And from that frame on at other random places.
I had to wait 10-30 minutes for each event, but it wasn't even a nice "crash", just something, somewhen was not freed properly from memory I didn't even know what to search for.
It appeared randomly. Turned out that when there was a lot of movement in the video, a number remained under a threshold and it was treated as a scene change.
And then (but only then) a program code was triggered that caused the memory leak.

Or the recent cache corruption issue in debug mode. 1/10000 sec differences here or there and how windows background processes were interrupting the avs code, sometimes the crash occured, but mostly not.
One crash vs twenty good encoding. The same script, same machine. Random. But it was reproducible, because it had happened.

[qyot27]

What is missing for cross platformity? I guess the first step that the project could be compiled with GCC?
The intrinsics have to be split up into separate files, and some parts (like the plugin loader) need to be rewritten or have a separate implementation to work on Linux or OSX. That's all I'm immediately aware of, aside from making sure none of the code is written in some MSVC-specific or GCC-specific dialect unless those compilers are the only ones ever touching that piece of code.

Pull request #45 (https://github.com/AviSynth/AviSynthPlus/pull/45) on Github already implements a basic set of the install rules that can be tailored better to fit *nix-specific shared objects when the time comes, but the basic process of getting stuff into the right install dir hierarchy is already there and works just fine on Windows with either NMake or Ninja controlling cl.exe (even though Windows doesn't use the Filesystem Hierarchy Standard, though Cygwin and MSys(2) both do).

innocenat started on the migration with the 'linux' branch, and I'd synced from it and started splitting the intrinsics on my side, but the run-up to integrating RC1 put that on the backburner and I haven't managed to pick it back up.

[MysteryX]

Random things. TemporalSoften memory leak occured after the 35000th frame in the QTGMC process. And from that frame on at other random places.
I had to wait 10-30 minutes for each event, but it wasn't even a nice "crash", just something, somewhen was not freed properly from memory I didn't even know what to search for.
It appeared randomly. Turned out that when there was a lot of movement in the video, a number remained under a threshold and it was treated as a scene change.
And then (but only then) a program code was triggered that caused the memory leak.

Or the recent cache corruption issue in debug mode. 1/10000 sec differences here or there and how windows background processes were interrupting the avs code, sometimes the crash occured, but mostly not.
One crash vs twenty good encoding. The same script, same machine. Random. But it was reproducible, because it had happened.
You're good to have nailed these down!

I haven't done much testing with your version yet, but I'll post more detailed stuff once I get to testing it more in-depth.

The way I was using AviSynth+ (non-MT, the most stable of all) was to load a preview AVS script within a Windows Media Player ActiveX control within my Natural Grounding Player application. After doing the 20-30th preview or so (which really is only opening up a script within a player), the whole application would hang. I haven't tested if it still happens with your version.

Or with SVP, there is the infamous bug that it would regularly and randomly freeze when loading videos. If you play around with SVP, I'm sure you'll see it freeze.

[chainik_svp]

The intrinsics have to be split up into separate files

Why? neither gcc nor clang requires that...

If it was my decision, I'd better took one solid and cross-platform core that's already here (e.g. vapoursynth :D) and just add a complete Avisynth API around it (which is already done (?) from the plugins PoV) plus an Avisynth script parser.
I really don't get what's the point in existence of three different half-working frame servers...

[MysteryX]

If it was my decision, I'd better took one solid and cross-platform core that's already here (e.g. vapoursynth :D) and just add a complete Avisynth API around it (which is already done (?) from the plugins PoV) plus an Avisynth script parser.
I really don't get what's the point in existence of three different half-working frame servers...
It would be faster to get AviSynth+ 100% working than to finish implementing such a bridge.

Plus VapourSynth doesn't support audio processing yet, nor can it be integrated with ffdshow.

Correct me if I'm wrong, but VapourSynth still needs a lot of work to be a replacement to AviSynth.

[chainik_svp]

We're talking about Avisynth+ port for Linux ;)

[MysteryX]

We're talking about Avisynth+ port for Linux ;)
Oh... for Linux. Getting into politics here.

Would all the standard AviSynth filters work on Linux or have to be rewritten and recompiled?

My opinion is that if all the plugins would work on Linux, porting AviSynth+ to Linux would be a great idea. If the plugins are window-specific, then the development may be better spent on VapourSynth.

Based on my limited C understanding, I do believe most plugins are limited to Windows but could be made cross-platform quite easily. Except my AviSynthShader that is and will always remain Windows-only :) (unless someone wants to port the dead DX9 API to Linux?)

All GPU-accelerated plugins may require more work to port.

[pinterf]

New AVS+ build: r1849 and vdubfilter.dll

x64/x86, including XP versions

r1849 MT-pfmod (20160422)
- Tweak internal FrameRegistry
- [VDubFilter.dll] Fix: VirtualDub filter x64 crash
- [VDubFilter.dll] Add: VirtualDub filter parameter type double

This build primarily aims to fix virtualdub x64 issues. Special thanks to jpsdr for providing the test environment.

Although avisynth.dll was not affected, since r1847 I put a minor tweak into the FrameRegistry logic (list->vector internally), sometimes it was faster a bit. So I included it also.

Download r1849 and vdubfilter.dll:
http://www.mediafire.com/download/fbtzo1pvo8aidoq/r1849-pfmod-with-vdubfilter.7z
or
https://github.com/pinterf/AviSynthPlus/releases/tag/r1849-MT-pfmod

[jackoneill]

It would be faster to get AviSynth+ 100% working than to finish implementing such a bridge.

Plus VapourSynth doesn't support audio processing yet, nor can it be integrated with ffdshow.

Correct me if I'm wrong, but VapourSynth still needs a lot of work to be a replacement to AviSynth.

Wasn't ffdshow abandoned by the maintainer, hence the need for lavfilters?

[qyot27]

Why? neither gcc nor clang requires that...
Clang may not require it, but GCC definitely does if you want a binary that's usable on anything older than the newest SIMD instruction set used in the intrinsics. Which means that AVX/AVX2 paths could not be added to the filters as soon as they're ready, because it would make CPUs older than Sandy Bridge/Haswell unable to run GCC builds of AviSynth+.

http://www.virtualdub.org/blog/pivot/entry.php?id=363

The 'workaround' for that (by littering __attribute__ or #pragma overrides throughout the file) is entirely either GCC-specific or messy, and thus, ineligible from how I understand the project coding guidelines. Not because it wouldn't work, but because it would also mean potentially adding tons of ifdefs just to make sure MSVC doesn't choke on them.

The only option that leaves us with is to split the intrinsics per-SIMD into discrete files, and then use the build system to add the correct -mSIMD flags when building the files that need them and omit them otherwise. In fact, x265 did just what I described when they still relied on intrinsics rather than on yasm. Several autotools-based projects in the FFmpeg dependency chain also segregate their intrinsics this way, likely for the exact same reason(s).

The thing that actually causes the problem is the inclusion of the intrinsics headers, which require the application of the -mSIMD flags in order to not fail compilation. But applying those project-wide means that codepaths that don't even use those SIMD sets will get optimized by the compiler for those sets, and become unable to run on anything lower. And the way to apply them per-file is to make sure the intrinsics are split into separate files so they don't contaminate each other.


At which point it might as well be stated that GCC won't be supported, only Clang (if it doesn't require these contortions to make the intrinsics and runtime detection work right).

[qyot27]

Oh... for Linux. Getting into politics here.

Would all the standard AviSynth filters work on Linux or have to be rewritten and recompiled?

My opinion is that if all the plugins would work on Linux, porting AviSynth+ to Linux would be a great idea. If the plugins are window-specific, then the development may be better spent on VapourSynth.

Based on my limited C understanding, I do believe most plugins are limited to Windows but could be made cross-platform quite easily. Except my AviSynthShader that is and will always remain Windows-only :) (unless someone wants to port the dead DX9 API to Linux?)

All GPU-accelerated plugins may require more work to port.
Even if no plugins could be ported to Linux*, getting AviSynth+ cross-platform is necessary to get AvxSynth out of the way for good and have a singular up to date AviSynth implementation that FFmpeg or x264 can use on non-Windows. AvxSynth has all its assembly disabled (some filters don't even work right) and is limited by the same constraints as AviSynth 2.5.8; it has a use, but it's severely limited and was mostly important because it made sure the libavformat demuxer for AviSynth was rewritten correctly. AviSynth+ wouldn't suffer from any of those problems, since the first release on a non-Windows OS would already incorporate the intrinsics, multithreading, and 2.6 colorspaces, and probably even get >8bit not long after if the effort was there.

*which is far from true; most plugins don't rely on Windows system calls (something IanB mentioned in the AvxSynth thread, as part of a musing that a thunking layer could make the Windows plugin *.dlls usable on Linux without recompiling them) and would only need to be able to be built by GCC or Clang with some fixes for how Linux expects libraries to act. And there's always the option of adding AviSynth+ interfaces to existing VapourSynth plugins that work better than their old AviSynth counterparts on Windows.

[pinterf]

Huh, it's not easy. I'd better stay in the background regarding any multiplatform things. Two month ago I even could not recognize that these codes were written in CPP. It was in 2000 when I was last using C :) In DOS I didn't need fancy constructor syntaxes. So I just listen and learn.

[MysteryX]

OK I've done some testing. The most stable with SVP is to use SVP 4.0.0.60 and MPC-HC 1.7.9 with AviSynth+. The latest SVP appears to crash more, so does MPC-HC 1.7.10 (maybe?)

After loading 20-30 videos in MPC-HC while playing with SVP, the player will freeze which requires to kill the process manually.

[Groucho2004]

OK I've done some testing. The most stable with SVP is to use SVP 4.0.0.60 and MPC-HC 1.7.9 with AviSynth+. The latest SVP appears to crash more, so does MPC-HC 1.7.10 (maybe?)

After loading 20-30 videos in MPC-HC while playing with SVP, the player will freeze which requires to kill the process manually.
What's the point of this post? Avisynth cannot magically fix the SVP and/or mpc bugs.

Also, have a look at this thread (http://www.svp-team.com/forum/viewtopic.php?id=3247). I'd refuse to look into anything related to SVP.