Avisynth+

[Reel.Deel]

Originally Posted by pinterf

Same happens to avisynth 2.6, because globals=1 is for read globals and Process

bv2 is a variable that a former processing phase outputs as global

You have to run a first phase in order to bv2 and the other variables exist.

ColorBars(pixel_type="YV12")
SMDegrain (globals=3) # 3 - Output globals only, don't process 
SMDegrain (globals=1) # 1 - Read globals and Process

Oops, you are totally correct. Its been a while since I've used SMDegrain. Sorry for the false alarm.

[qyot27]

Okay, challenge/project time.

Does anyone have a definitive (or near-definitive) list of C-plugins that have been written? Browsing the External Filters page on the wiki only brings up four or five (ColorDiff, FFMS2's C-plugin variant, AssRender, the old Yadif, and I feel like I'm probably forgetting another one...). Additionally, how many of them besides FFMS2 can be built as 64-bit?

The reason for this is part of my attempting to determine the best course of properly addressing pull request #41.

For those interested, even if I supplied 64-bit builds of FFMS2's C plugin like I do for 32-bit, you can't use them with 64-bit AviSynth+, because it rejects them as invalid. If you fix 64-bit C plugin loading by applying the 'fix' from that pull request, 32-bit C plugins get seen as invalid in 32-bit AviSynth+.

So to quote my response on the pull request,

Perhaps it's not this complicated and there is a middle ground that can work for both (or something we need to add to the C API doc page to account for this weirdness if this is something that only plugin authors can do). But this pull request as it is is not the solution to this problem.

EDIT: I mean, the ugly, kinda-hackish way of fixing it would be to branch the C plugin check so that it does one thing if _WIN64 (a macro that I keep forgetting exists) is true and a different one otherwise, but hopefully there's a better way than that.

[pinterf]

Originally Posted by qyot27

EDIT: I mean, the ugly, kinda-hackish way of fixing it would be to branch the C plugin check so that it does one thing if _WIN64 (a macro that I keep forgetting exists) is true and a different one otherwise, but hopefully there's a better way than that.

As for Microsoft: "Note that in a 64-bit environment, functions are not decorated."
https://msdn.microsoft.com/en-us/lib...2.aspx#FormatC
For other compilers, I don't know.

So in 64 bit it looks like avisynth_c_plugin_init
In 32 bit _avisynth_c_plugin_init@4

Avisynth+ now tries with then w/o underscore
First: _avisynth_c_plugin_init@4
Then if fails: avisynth_c_plugin_init@4

I think, none of them matches with x64

The proposed patch tries the 64 bit convention first, then the 32 bit one
First: avisynth_c_plugin_init
Then if fails: _avisynth_c_plugin_init@4

I think the final patch can keep the two old version (with and without underscore) but would attempt to use the undecorated version before them.

[Groucho2004]

FYI - "avisynth_c_plugin_init" is what old C2.0 plugins export.

The "official" avisynth code looks first for the C2.5 export "avisynth_c_plugin_init@4" and if that fails for the C2.0 export "avisynth_c_plugin_init".

Of course this is moot since AVS+ doesn't support C2.0 plugs at all.

As for the determination whether a plugin to be loaded is 64 bit or 32 bit I would use the MapAndLoad() API and then examine the PE header. It's just a few lines of code (shown without any error handling):

LOADED_IMAGE li;
MapAndLoad("something.dll", NULL, &li, TRUE, TRUE);
if (li.FileHeader->FileHeader.Machine == IMAGE_FILE_MACHINE_I386)
{
 //32 bit module
}
else
{
 //64 Bit module
}
UnMapAndLoad(&li);

[pinterf]

Unlike this problematic version, when trying to load AvisynthPluginInit2 and AvisynthPluginInit3 the undecorated version is used on the first place.

AvisynthPluginInit2Func AvisynthPluginInit2 =
         (AvisynthPluginInit2Func)GetProcAddress(plugin.Library, "AvisynthPluginInit2");
if (!AvisynthPluginInit2)
  AvisynthPluginInit2 = 
         (AvisynthPluginInit2Func)GetProcAddress(plugin.Library, "_AvisynthPluginInit2@4");

Loading avisynth_c_plugin_init misses this option

[jackoneill]

In case you were wondering why it even checks for a partially decorated function: it's what you get by default when cross-compiling with gcc/mingw.

[qyot27]

I initially tried to do a cleaner version that simply set #defines and used those in the normal init checker, but that didn't work, so I just did it the way I'd hoped I wouldn't have to:
https://github.com/AviSynth/AviSynthPlus/pull/66

End result: 64-bit AviSynth+ can use 64-bit FFMS2-C, 32-bit AviSynth can use 32-bit FFMS2-C.

For those wanting to test:
http://www.mediafire.com/download/40...dd-20160607.7z
http://www.mediafire.com/download/i7...Bvsp-test64.7z

[qyot27]

Originally Posted by jackoneill

In case you were wondering why it even checks for a partially decorated function: it's what you get by default when cross-compiling with gcc/mingw.

The other thing I'd been considering is that the function decorations and such should be the task of the plugin author to get right, not of AviSynth+ to handle.

The only problem with that is that up until now, it was either never considered and/or never enforced, and there's no mention of it in the C API docs so that plugin authors can make sure GCC or MSVC decorates the stuff correctly.

So I support either case here: either AviSynth+ checks for the way the compilers are set up by default (leading to branching the init check as per pull #66), or we get strict about how the functions get decorated in C plugins and provide this guidance in the documentation so plugin authors can do so correctly (in which case I'll then fix FFMS2 instead).

[pinterf]

qyot27, integrated your changes, commit comment links to your pull request

[ajp_anton]

crop handles RGB as expected, but crops while resizing (the arguments after the target width/height) are reversed. Can this be fixed, or am I missing the reason for why this is?

[MysteryX]

Originally Posted by ajp_anton

crop handles RGB as expected, but crops while resizing (the arguments after the target width/height) are reversed. Can this be fixed, or am I missing the reason for why this is?

This was fixed in the latest release

[StainlessS]

RGB is upside down, perhaps somebody forgot
(is it just top/bottom that are wrong)

EDIT: Just beaten by MX.

[qyot27]

Originally Posted by pinterf

qyot27, integrated your changes, commit comment links to your pull request

...

For future reference, this is sort of the exact reason* that git's cherry-pick or format-patch/am options exist.

*read: the commit can be applied as-is but you don't want to litter the git history with merge commits.

[pinterf]

Originally Posted by Reel.Deel

I recently tried with this script and get a similar error "I don't know what 'z3' means". Disable MT and the script works just fine.

Import("MTModes.avsi")
Import("crt_display.avsi")

SetFilterMTMode("DEFAULT_MT_MODE", 2)

ColorBars()
Trim(0,500)

ar = 10.0 / 11.0
crt_display (2*ar, 2, ppp=1*ar, blurh=2.0)

Prefetch(4)

After three day of debugging I finally I came to the conclusion that Eval should be forced as NICE_FILTER.

The problem was that although Eval is a special passthrough script function, its behaviour was affected by setting the default mt mode.

When Eval is set to MT mode 2 (by setting default mt mode), but the last filter () inside Eval was NICE_FILTER, plus this filter is forced to have no cache, creation of Eval's MT guard entries inside the core are executed after Prefetch. But since in the problematic scenario this Eval was inside a function, it had lost its variable context: could not access the function-local z3 variable anymore.

The real mt behaviour is still defined by the content of the script passed to Eval as parameter.

[MysteryX]

Wow pinterf that's a good one!

It might take 3 days of debugging to catch such a small tricky detail, but it's by taking the time to do this for every little bug that we're going to get a stable platform. It just takes someone crazy enough to put their hands into it

There's one small bug I've been occasionally seeing while playing via SVP, that I mentioned earlier. "Sometimes" when it re-initializes the playback, some parts of the video are covered by pain green zones for a very brief period and then everything is fine. I've *never* seen this issue while using AviSynth in any other way, so I have suspicions that the memory corruption might be related to the way it relates with ffdshow. Since it's rare and random, it's very hard to reproduce and debug.

I've also been thinking about your idea of adding 16-bit support. As it has been proven by configuring SetMTFilterMode only when running AVS+, it's possible to write a plugin that works on both AVS 2.6 and AVS+ and that will provide extra features only if running on AVS+. Thus, a filter can support 16-bit when running on AVS+ while still providing regular 8-bit support for other versions.

Then, at first, it might be like Dither Tools that is integrated into the core and faster. If there is a replacement to Dither Tools in the core (16-bit resize, etc), then that would definitely be useful in and of itself. Then on top of that, over time, some developers will add 16-bit support into their plugins, but we'd have benefits even if few other filters support it.

[MysteryX]

I can know whether an MT version of AviSynth is running like this

bool IsMt = env->FunctionExists("SetMTMode") || env->FunctionExists("SetFilterMTMode");

Is there a way to know whether MT mode is actually enabled? Does the AVS+ extended interface provide information about the current MT status?

[Groucho2004]

Originally Posted by MysteryX

Is there a way to know whether MT mode is actually enabled? Does the AVS+ extended interface provide information about the current MT status?

See posts #546 and #550.

[LigH]

In the original AviSynth MT, you could request GetMTMode(false) if available. No clue about AviSynth+ returning the Prefetch(threads) value, though; and there may be a reason why it has to be used as very last command in a script...
_

P.S.:

Originally Posted by Groucho2004

See posts #546 and #550.

Kindly providing a link to #546

In brief: Due to the association of modes with filters, instead of the script position, requesting the "current mode" is not supported in AVS+. For plugin developers, the IScriptEnvironment2 interface has a property to return the thread count.

[MysteryX]

Originally Posted by LigH

Kindly providing a link to #546

Thanks!

Yes, you can tell that using IScriptEnvironment2::GetProperty(AEP_FILTERCHAIN_THREADS), but please don't use it before the whole IScriptEnvironment2 is finalized. This is not a licensing restriction, it has to do with the fact that if you start using it and the class changes after that, your application will break.

What is the right way to use it so that it doesn't crash if the API changes?

For now I have this

// Runs as MT_NICE_FILTER in AviSynth+ MT, otherwise MT_MULTI_INSTANCE
isMT = false;
if (env->FunctionExists("SetFilterMTMode")) {
	auto env2 = static_cast<IScriptEnvironment2*>(env);
	isMT = SUPPORT_MT_NICE_FILTER && env2->GetProperty(AEP_FILTERCHAIN_THREADS) > 1;
}

[Chikuzen]

Hi.

It seems that FlipHorizontal is broken on RGB32.


patch

diff --git a/avs_core/filters/transform.cpp b/avs_core/filters/transform.cpp
index c56a56e..390ea53 100644
--- a/avs_core/filters/transform.cpp
+++ b/avs_core/filters/transform.cpp
@@ -156,7 +156,7 @@ PVideoFrame FlipHorizontal::GetFrame(int n, IScriptEnvironment* env) {
   if (vi.IsRGB32()) {
     for (int y = 0; y<height; y++) {
       for (int x = 0; x<width/4; x++) {
-        *reinterpret_cast<int*>(dstp+x) = *reinterpret_cast<const int*>(srcp-x);
+        (reinterpret_cast<int*>(dstp))[x] = (reinterpret_cast<const int*>(srcp))[-x];
       }
       srcp += src_pitch;
       dstp += dst_pitch;