Thread: Avisynth+
View Single Post
Old 7th August 2018, 03:26   #4178  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 197
Quote:
Originally Posted by FranceBB View Post
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):
Code:
    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:
Code:
#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:
Code:
__attribute__((dllimport)) int avs_is_yv24(const AVS_VideoInfo * p);
when they should be this:
Code:
 __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.)
mkver is offline