Avisynth+

[qyot27]

Here's a build that supports Pentium III. The revision number is higher because it came from some work I'd done to make it compile a little bit more easily/cleanly with MinGW, so nothing markedly different from the latest build from pinterf (especially since I built it with MSVC 2017).

[manolito]

Thanks so much, this is so nice of you...

Gives me something to play with for the next couple of days. Of course I need to stick with my old MaskTools and MVTools, and this means that I also keep my older QTGMC, LSFMod and SRestore scripts because the "modernized" scripts depend on the latest PinterF versions. I am curious if I will still get some speed gains.

Two questions:
1. I know that AVS+ can autoload C-Plugins. Do I have to make any changes in my autoload folder? Right now I autoload my C-Plugins with the help of an AVSI script which loads the C-Plugins.

2. Of cource my P3 Coppermine is single threaded. Would it still make any sense to add the "Prefetch" command to the end of my AVS scripts?


Thanks again
manolito

[Groucho2004]

Originally Posted by manolito

Two questions:
1. I know that AVS+ can autoload C-Plugins. Do I have to make any changes in my autoload folder? Right now I autoload my C-Plugins with the help of an AVSI script which loads the C-Plugins.

2. Of cource my P3 Coppermine is single threaded. Would it still make any sense to add the "Prefetch" command to the end of my AVS scripts?

1. You simply remove that .avsi from the auto-load directory.

2. No. It would even reduce performance.

[manolito]

[StainlessS]

Qyot27, Top man, your efforts are always much appreciated, alas, my PIII's now all long dead.

1), I like to load C plugins via avsi (from separate sub directory of 'Plugins') as I just dont like them in my plugs (maybe in case I revert to Std
for some temp reason). [I usually enable on demand just by uncommenting a line in avsi].
{just an option to consider, at least keep a copy of original avsi in a SCRIPT sub directory of your Plugins archive}

[Groucho2004]

Originally Posted by StainlessS

I like to load C plugins via avsi (from separate sub directory of 'Plugins') as I just dont like them in my plugs (maybe in case I revert to Std
for some temp reason). [I usually enable on demand just by uncommenting a line in avsi].

Same here, more or less. I only have the plugins I use frequently in the autoload directory (mvtools, masktools, rgtools, f3kdb ...) and load others as needed from another location.

Of course there are people who take auto-loading to a new level:
https://forum.doom9.org/showthread.p...94#post1844394

[manolito]

Just gave qyot27's Non-SSE2 version from this post
https://forum.doom9.org/showthread.p...75#post1847975
a whirl on my ancient computer, and I am impressed...

To avoid any installation mistakes I installed the latest pinterf version first, then replaced the files with the ones from the qyot27 build. During installation I opted for uninstalling the old AVS version and migrate the old plugins.

Worked on the first attempt. AVStoDVD issued a non-fatal warning about a wrong AviSynth version on startup, but that was it. All my standard scripts worked out of the box. I have 76 plugins in my autoload folder, and so far none of them caused a crash.

BTW is there an easy method to identify ancient 2.0 C-plugins?

Only my old and beloved DVDtoSVCD absolutely refused to work under AVS+. It needs AVS 2.57 anyways, I have to use Groucho's AVS switcher to make it work.

Next I did a few speed comparisons. The specs of this ancient machine are:
Celeron P3 Coppermine @ 1.1 GHz Non-SSE2 Single Core
576 MB system RAM
Win XP SP3 32-bit

The unmodified scripts ran a tiny bit slower than under AVS 2.61 Alpha (42 fps vs. 46 fps). Just for fun I then added Prefetch commands to the end of my scripts, and to my big surprise this was very stable and did not compromise speed. Even using "Prefetch(8)" caused no problems. And remember this is under a single core CPU with very low system RAM. Quite impressive...


So again a big thanks to qyot27 for this build. Even if it has no advantages on my old machine it will definitely make it much easier for me to maintain my AviSynth installations on my various computers because I will only have to deal with one identical installation for all of them.


Cheers
manolito

[Groucho2004]

Originally Posted by manolito

BTW is there an easy method to identify ancient 2.0 C-plugins?

"AVSMeter avsinfo"

If you want to specify a custom plugin directory:
"AVSMeter avsinfo -c"

[StainlessS]

BTW is there an easy method to identify ancient 2.0 C-plugins?

Just AvsMeter as far as I'm aware.

Although you might be able to chop something out of this (dont know how it fares under AVs+, no idea what 'not supported' means in that case).
https://forum.doom9.org/showthread.p...95#post1641795

C v2.0 plugs I got (maybe not all of them)

avisynth_c.dll  # The loader, not C v2.0

AVSCurveFlow.dll
AVSShock.dll
equlines.dll
IBob.dll
SmartDecimate.dll
Transition.dll

EDIT: Damn that Groucho, he's just too fast.

[qyot27]

Good to know that it worked; when I tried moving it over to my P3 machine to test it myself, I ran into redist problems (and couldn't resolve them because the Windows Installer service on that install is screwed up something fierce), so I was flying blind a little bit.

I did, however, whip up a patch to let the SIMD level be selected during configuration. It seemed to work, since when I told it to optimize for AVX, the .dll would no longer run on this (Apollo Lake-based, only has up to SSE 4.2) computer.

[manolito]

Now I am just curious how big the speed sacrifice using this non-SSE2 version vs. the standard version is. I still assume that the various filter plugins will be the bottleneck and not AviSynth itself...


Cheers
manolito

[jpsdr]

It's not impossible you may encoder speed loss with internal core avs filters. The old version you were using had internal asm MMX optimized code. The new avs+, everything has moved to intrinsics, but i think they need at least SSE2. So, it's possible that now you have only pure code C path, instead of MMX optimized code. But i don't know exactly what qyot27 has done, so it's up to him to confirm or not what i've said.

[pinterf]

In a non-SSE2 build MMX code is still there since it was also moved from the classic Avisynth or got rewritten to intrinsics.
New stuff (mostly for high bit-depth) was implemented in C-only at the beginnings and the SSE2 option gave quite a good optimization for these parts. Since then most of the things have hand-written SSE2/SSE4 optimization, some have AVX2.
I haven't stopped or removed the C implementation, all filters and function have the C version.

[jpsdr]

Originally Posted by pinterf

In a non-SSE2 build MMX code is still there since it was also moved from the classic Avisynth or got rewritten to intrinsics.

Ah, i was wrong on this part, my mistake.

[qyot27]

All the MSVC optimization flags (/arch:SSE2 vs. /arch:SSE or /arch:IA32) do is optimize the C portions to emit SIMD instructions in the compiled binary, it's not necessary to match it with the intrinsics; the intrinsics will compile to the proper SIMD-enhanced versions with or without /arch set. GCC largely works the same way with its -march/-mtune/-mCPU flags (except that GCC's handling of branched intrinsics is a complete rat's nest).

[wonkey_monkey]

I'm on r2506 and always scared of installing a new version. I've noticed that showy, showu, and showv all cause exceptions. Just thought I'd mention it in case it's still a bug. Extracty/u/v all work fine.

[StainlessS]

and showv all cause exceptions

Confirmed in r2728.
EDIT: Dont be a scaredy-cat David, recent versions of avs+ have had some nice speed improvements and I'm sure that r2728
crashes way faster than the old r2506 that you are using.

[mkver]

Originally Posted by FranceBB

Only ancient 2.0 C plugins like InpaintFunc, a delogo I've been using for years, but there are alternatives, so I don't mind.

What exactly do you mean by "make Avisynth+ crash"? Is it the mere presence of a plugin's dll in the plugin's folder enough to make it crash? (InpaintFunc is btw. a script, not a plugin; it uses AVSInpaint internally.) This is something that I couldn't reproduce, neither with the first version of AVSInpaint (that still relied on AviSynth_C.dll) nor with the second version that is a proper 2.5 C plugin.

But I know that AVSInpaint is indeed a bit buggy. I have already asked pinterf about the different behaviour of AVSInpaint on AVS+ and AVS 2.6 (after all, it might have been a bug in AVS+) and it turned out to be a bug in AVSInpaint (as expected):

    if (AlphaFrame)  avs_release_video_frame(LogoFrame);
    if (LogoFrame)  avs_release_video_frame(LogoFrame);

The above double part of AVSInpaint.c is contained in the code path for deblending of a static logo. Inpaintfunc makes use of exactly this part of AVSInpaint.c when deblending, therefore it crashes. Thanks again to pinterf for finding this bug.

I managed to compile both x86 and x64 versions of AVSInpaint; I actually did this already in May, but back then I created the necessary x64 AviSynth.lib by using avisynth.def from github and dlltool (part of MinGW64) and "dlltool -l avisynth.lib -d avisynth.def /c/Windows/System32/AviSynth.dll" from the 2664 AVS+ dll and although the resulting plugin worked, I wanted to wait for an officially released lib file (pinterf mentioned that he would add (as he has now) them to his releases) and of course I forgot about them, but your post reminded me of this. Here are the builds. Could you confirm that you don't get any more crashes with them and that they work as intended?

I also think to have found a bug in AVS+. capi.h contains these lines:

#ifdef MSVC
#ifndef AVSC_USE_STDCALL
#  define AVSC_CC __cdecl
#else
#  define AVSC_CC __stdcall
#endif
#else
#  define AVSC_CC
#endif

#define AVSC_INLINE static __inline

#ifdef BUILDING_AVSCORE
#  define AVSC_EXPORT __declspec(dllexport)
#  define AVSC_API(ret, name) EXTERN_C AVSC_EXPORT ret AVSC_CC name
#else
#  define AVSC_EXPORT EXTERN_C __declspec(dllexport)
#  ifndef AVSC_NO_DECLSPEC
#    define AVSC_API(ret, name) EXTERN_C __declspec(dllimport) ret AVSC_CC name
#  else
#    define AVSC_API(ret, name) typedef ret (AVSC_CC *name##_func)
#  endif
#endif

I think the "# define AVSC_CC" should be "# define AVSC_CC __stdcall" (or maybe one shouldn't test for MSVC at all here). Compiling x64 with the present capi.h worked, because there is only one calling convention for x64 Windows (so cdecl and stdcall decorations are ignored when the target platform is x86-64). But compiling x86-32 didn't work, because the AVSC_API functions don't get declared as stdcall. After the preprocessing stage they look like this:

__attribute__((dllimport)) int avs_is_yv24(const AVS_VideoInfo * p);

when they should be this:

 __attribute__((dllimport)) int __attribute__((__stdcall__)) avs_is_yv24(const AVS_VideoInfo * p);

(This is also what gets produced when one uses an old AviSynth_C.h header file from AVS 2.6.)

[qyot27]

There was a capi-related commit fairly recently messing with the dllexport/dllimport stuff, but there was no description of what it was supposed to fix. It did indeed used to compile just fine with MinGW-w64 regardless of 32-bit* and 64-bit, and I'd addressed a compatibility workaround with calling convention in my branch, but it was incredibly hackish.

*32-bit GCC builds would not work with FFmpeg, though, due to 32-bit calling conventions. That is, unless using the regressed HEAD version of the header that allows for building AviSynth+ with GCC. But then 32-bit MSVC builds won't work. That hack above was to mitigate this and default to the program still working with 32-bit MSVC builds.

[pinterf]

Originally Posted by davidhorman

I'm on r2506 and always scared of installing a new version. I've noticed that showy, showu, and showv all cause exceptions. Just thought I'd mention it in case it's still a bug. Extracty/u/v all work fine.

Fixed on git.