Avisynth+

[Reel.Deel]

A while back NightSprinter reportred this problem with crt_display (http://forum.doom9.org/showthread.php?t=170732) while using MT.

This is odd, running a Core i7 920 (4 cores, 8 threads) with everything done as posted on the tutorial. However, when I enable prefetch, I get an error along the lines of "I don't know what 'zb' means". I'm using the latest AVS+ installer from the wiki page, and the filter script chain I'm using is the CRT simulation filter that's on this forum as well. I'm including the script in .txt format

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. :confused:

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)

[jpsdr]

Question about the multi-threading parts.
In case filter is MT_NICE, or MT_MULTI_INSTANCE. Especialy for this last case, are the multiple instances of the filter real different instances, or should i worry about eventualy copy constructor issues ?

[pinterf]

Strange.

O.K. (Default MT = 3 + Eval + Function Call)
SetFilterMTMode("DEFAULT_MT_MODE", 3)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}


Fail, (Default MT = 2 + Eval + Function call)
# I dont' know what 'r' means
SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}


O.K. (Default MT = 2 + NO Eval + Function call)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
#Eval("Interleave (r, g, b)")
Interleave (r, g, b) # ok
}


O.K (Default MT = 2 + Eval + no function call)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

#test()

r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")

Prefetch(1)

[MysteryX]

Question about the multi-threading parts.
In case filter is MT_NICE, or MT_MULTI_INSTANCE. Especialy for this last case, are the multiple instances of the filter real different instances, or should i worry about eventualy copy constructor issues ?
With MT_MULTI_INSTANCE, they are completely separate instances. The only way the various instances can communicate with each other is through global variables.

[bilditup1]

I will continue doing tests and reporting back, especially with respect to how well 1080i works and regarding matrix operations.

Tested 1080i60 with downscaling to 360p30 and matrix conversion from 709 to 601, and getting some weird results. Download screenshots and scripts here (https://mega.nz/#!GAgBgQIJ!NLBwb567WQyfi3w8r6jPymNqzfEYmWrZiTmIdDhPMbM). I think the file naming/numbering is intuitive and you guys should be able to figure it out.

Four passes:


just straight downscaling (Spline36) and deinterlacing, no matrix operations. This yielded 10.17fps (including x264 compression).
using ColorMatrix for 709->601. This was done in almost real-time, yielding 10.06fps.
using Dither for 709->601 and downscaling (still using Spline36 kernel). Slowed things down significantly, only got 6.32fps, which I guess is to be expected.
using AviSynthShader for 709->601 and downscaling (using Bicubic kernel). Slowed things down even more, only got 5.85fps - again, to be expected with a lowly HD4600 - and MeGUI crashed at 99.83% (there's a screenshot of this in the zip).
I had intended to do comparisons with this last also, after muxing the 264. However I had neglected to delete the original encoding job from the MeGUI queue, and as a result the original file got destroyed once the queue commenced - instead of the muxing job, it tried to do the encode again, since when MeGUI itself totally crashes, the job that causes the crash is never marked as done, and shows up as 'waiting' in the queue - and I didn't want to wait for the encode to finish before I posted here. In any case, it's not really relevant to me right now, so I left it be.

A few observations:

CPU, when I bothered to check, was running at at least 60%.
I had to disable MT for the comparison clips (using FFMS2), otherwise the overlays with the frame-numbers and such got garbled and destroyed.
1080i in and of itself does not appear to be an issue.
But, from these clips it looks like ColorMatrix might in fact still be causing problems?
In frame 0, the scrolling text is corrupted on the bottom right, only in the ColorMatrix one (not in the others or the source).
At frame 39287, there are big green horizontal bars across the upper middle and bottom of the frame.
Both of these only show up in an actual encode, not in the mere preview (using AvsPmod, for example).
There might be other problems, but they were too quick to catch.

Dither has some weirdness, too. The first two frames look like some interlaced abortion of some kind. But, again, this only happens in an actual encode.
All of them had trouble at 29300...but this turned out to be in the source. I've included it because it's a pretty weird artifact and I'm curious as to what could cause it.
Due to the nature of these problems - crashing/not crashing with no modifications to the avs, problems showing up in the encode but not the preview, &c - I'm beginning to suspect that perhaps my overclock is too aggressive. So I think you may need to take all of these with a grain of salt. I'll be fiddling with that and trying again once I get back in town.

[Groucho2004]

Tested 1080i60 with downscaling to 360p30 and matrix conversion from 709 to 601, and getting some weird results. Download screenshots and scripts here (https://mega.nz/#!GAgBgQIJ!NLBwb567WQyfi3w8r6jPymNqzfEYmWrZiTmIdDhPMbM). I think the file naming/numbering is intuitive and you guys should be able to figure it out.

Four passes:


just straight downscaling (Spline36) and deinterlacing, no matrix operations. This yielded 10.17fps (including x264 compression).
using ColorMatrix for 709->601. This was done in almost real-time, yielding 10.06fps.
using Dither for 709->601 and downscaling (still using Spline36 kernel). Slowed things down significantly, only got 6.32fps, which I guess is to be expected.
using AviSynthShader for 709->601 and downscaling (using Bicubic kernel). Slowed things down even more, only got 5.85fps - again, to be expected with a lowly HD4600 - and MeGUI crashed at 99.83% (there's a screenshot of this in the zip).
I had intended to do comparisons with this last also, after muxing the 264. However I had neglected to delete the original encoding job from the MeGUI queue, and as a result the original file got destroyed once the queue commenced - instead of the muxing job, it tried to do the encode again, since when MeGUI itself totally crashes, the job that causes the crash is never marked as done, and shows up as 'waiting' in the queue - and I didn't want to wait for the encode to finish before I posted here. In any case, it's not really relevant to me right now, so I left it be.

A few observations:

CPU, when I bothered to check, was running at at least 60%.
I had to disable MT for the comparison clips (using FFMS2), otherwise the overlays with the frame-numbers and such got garbled and destroyed.
1080i in and of itself does not appear to be an issue.
But, from these clips it looks like ColorMatrix might in fact still be causing problems?
In frame 0, the scrolling text is corrupted on the bottom right, only in the ColorMatrix one (not in the others or the source).
At frame 39287, there are big green horizontal bars across the upper middle and bottom of the frame.
Both of these only show up in an actual encode, not in the mere preview (using AvsPmod, for example).
There might be other problems, but they were too quick to catch.

Dither has some weirdness, too. The first two frames look like some interlaced abortion of some kind. But, again, this only happens in an actual encode.
All of them had trouble at 29300...but this turned out to be in the source. I've included it because it's a pretty weird artifact and I'm curious as to what could cause it.
Due to the nature of these problems - crashing/not crashing with no modifications to the avs, problems showing up in the encode but not the preview, &c - I'm beginning to suspect that perhaps my overclock is too aggressive. So I think you may need to take all of these with a grain of salt. I'll be fiddling with that and trying again once I get back in town.

You are posting in the wrong thread. None of this is related to AVS+.

[bilditup1]

You are posting in the wrong thread. None of this is related to AVS+.

It most certainly is. The latest MT_modes list still has warnings about processing 1080i and about using the ColorMatrix plugin. These warnings have been there for years and nobody has bothered to verify them in ages. See the discussion starting here (https://www.doom9.org/showpost.php?p=1769237&postcount=1688).

[Groucho2004]

It most certainly is.
I'm beginning to suspect that perhaps my overclock is too aggressive.
Even if it were, do really think anyone will bother to look at your results after the above statement?

[bilditup1]

Even if it were, do really think anyone will bother to look at your results after the above statement?

I have only vague suspicions though. If this is a stability issue I have not seen other symptoms. BOINC runs all the time without errors, programs open the way they should, no BSoDs or random restarts. I included that disclaimer for completion's sake.

[ryrynz]

You are posting in the wrong thread. None of this is related to AVS+.
Did you really need to quote that entire unrelated post? Lol.


I have only vague suspicions though. If this is a stability issue I have not seen other symptoms. BOINC runs all the time without errors, programs open the way they should, no BSoDs or random restarts. I included that disclaimer for completion's sake.

That doesn't matter.. Instability can often go unseen. Go back to defaults and retest.

[bilditup1]

That doesn't matter.. Instability can often go unseen. Go back to defaults and retest.

...yes...hence my suspicions...I was just saying that there wasn't a traditional smoking gun just yet. I will in fact be retesting a few times and at stock, plus hopefully on another machine entirely if I can manage it.
I will also split off the rest of this discussion to its own thread. Not here to make trouble - just trying to make a positive contribution.

[MysteryX]

Ever since I added Dither Tools in this script, sometimes it works and sometimes it crashes the encoder or MPC-HC or freezes VirtualDub.

I tried running the same under AviSynth 2.6 MT and opened it 10-15 times without any crash or freeze. I'm guessing the most likely cause is a difference in MT modes for one of the DitherTools filters.


P="Encoder\"
Import(P+"AviSynthMT.avsi")
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"Dither.dll")
Import(P+"Dither.avsi")
LoadPlugin(P+"KNLMeansCL.dll")
LoadPlugin(P+"svpflow1.dll")
LoadPlugin(P+"svpflow2.dll")
Import(P+"InterFrame2.avsi")
Import(P+"ResizeX.avsi")
LoadPlugin(P+"Shaders\Shader.dll")
Import(P+"Shaders\Shader.avsi")

file="VCD.mpg"
LWLibavVideoSource(file, cache=False, threads=1)
AudioDub(LWLibavAudioSource(file, cache=False))
Crop(0, 0, -8, -0)
Dither_convert_8_to_16()
Dither_resize16(Width, Height/2, kernel="Spline36", csp="YV24")
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=0, lsb_inout=true)
SuperResXBR(5, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, MatrixIn="601", lsb_in=true, lsb_out=true)
Dither_resize16(Width, Height/2, kernel="Spline36", csp="YV12", invks=true)
DitherPost()
InterFrame(Cores=8, Tuning="Smooth", NewNum=60, NewDen=1, GPU=true)
SuperResXBR(3, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, fWidth=1012, fHeight=778, fKernel="Bicubic", fB=0, fC=.75)
ResizeX(1004, 768, 0, 5, -8, -5)
Prefetch(8)


By the way, LWLibavVideoSource runs with MT mode 3 which means there is a single instance? In that case, I don't need to specify 1 thread and I should just let it manage its own threats, correct?

[MysteryX]

I have set all DitherTools functions to MT mode 2. The first time I opened it, it freezed again, but afterwards I couldn't get it to freeze again. Dither Tools will require more testing for its MT compatibility/stability level.

By the way, at the top of the MT modes list, there should be a link to where the list actually came from and how to update it. When I want to refer changes about it, I don't even remember where it came from and who wrote it.

[pinterf]

This "I dont' know what 'r' means" is not an easy bug hunt.
At least now I know how to reproduce it.

All these conditions must be me met:

MT is on (Prefetch(x))
Eval is set to MT_MULTI_INSTANCE
either by SetFilterMTMode("Eval", MT_MULTI_INSTANCE)
or
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
Eval is within a function
Within Eval the last filter is NonCacheableVideoFilter
(responds != 0 to SetCacheHints(CACHE_DONT_CACHE_ME, 0))
Such filters: Trim, DuplicateFrame, Interleave, etc.
The last filter in Eval in the function is NICE_FILTER


There were quite a few permutations of these possible cases.

Sample scripts.

Fail. "I dont' know what 'r' means"
Eval MT mode 2 + function call + last filter in Eval is non cacheable and NICE_FILTER (Interleave)

SetFilterMTMode("Eval", 2)
#or SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}

O.K. - MT mode 2 + last filter in Eval is cacheable (StackVertical)

SetFilterMTMode("Eval", 2)
#or SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("a=Interleave (r, g, b)
StackVertical(a,a)")
}

O.K. - Eval MT mode 1

SetFilterMTMode("Eval", 1)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}

[pinterf]

I have set all DitherTools functions to MT mode 2. The first time I opened it, it freezed again, but afterwards I couldn't get it to freeze again. Dither Tools will require more testing for its MT compatibility/stability level.

By the way, at the top of the MT modes list, there should be a link to where the list actually came from and how to update it. When I want to refer changes about it, I don't even remember where it came from and who wrote it.
Can it be that the memory is simply not enough? What happens is you downsize the original video to 320x200? Or use only Prefetch(4)?

[Reel.Deel]

This "I dont' know what 'r' means" is not an easy bug hunt.
At least now I know how to reproduce it...

I found another scenario where it happens but this time without MT.

This works, but if I change SMDegrain() to SMDegrain(globals=1) I get "I don't know what 'bv2' means". I do not know how to reproduce this without SMDegrain (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution) but if I find an alternative I'll let you know.

ColorBars(pixel_type="YV12")
SMDegrain ()

[MysteryX]

Setting DitherTools to MT=3 appears to work so far. Will have to test which filter breaks with MT=1 or MT=2.

Memory usage is only ~900MB.

[MysteryX]

DitherPost appears to be the one crashing. This works so far.


SetFilterMTMode("DitherPost", MT_SERIALIZED)


The other DitherTools filters appear to work with MT_NICE_FILTER although I haven't tested all of them.

[pinterf]

DitherPost appears to be the one crashing. This works so far.


SetFilterMTMode("DitherPost", MT_SERIALIZED)


The other DitherTools filters appear to work with MT_NICE_FILTER although I haven't tested all of them.
Setting one filter to a stricter MT mode affects the timing and parallel execution conditions of the other filters in the chain, too. So unfortunately you cannot say that DitherPost is culprit. We can only state that bottlenecking MT at DitherPost solves this problem.

[pinterf]

I found another scenario where it happens but this time without MT.

This works, but if I change SMDegrain() to SMDegrain(globals=1) I get "I don't know what 'bv2' means". I do not know how to reproduce this without SMDegrain (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution) but if I find an alternative I'll let you know.

ColorBars(pixel_type="YV12")
SMDegrain ()
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

[Reel.Deel]

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 (https://github.com/AviSynth/AviSynthPlus/pull/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]

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/library/56h2zst2.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/40b03f39ghip7w1/avisynth__r1826-g8d447dd-20160607.7z
http://www.mediafire.com/download/i78pcwd2m8c0yov/ffms2_r1110%2B100-avs%2Bvsp-test64.7z

[qyot27]

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]

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]

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 (https://git-scm.com/docs/git-cherry-pick) or format-patch (https://git-scm.com/docs/git-format-patch)/am (https://git-scm.com/docs/git-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]

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. :confused:

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]

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.:

See posts #546 and #550.

Kindly providing a link to #546 (http://forum.doom9.org/showthread.php?p=1666404#post1666404) ;)

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]

Kindly providing a link to #546 (http://forum.doom9.org/showthread.php?p=1666404#post1666404) ;)
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.
https://dl.dropboxusercontent.com/u/19797864/fh_bug.png

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;

[pinterf]

Chikuzen, thank you, fixed.

[ultim]

I came to visit the forums, and after catching up with this thread, boy I cannot express how glad I am that pinterf picked up where I left. I am sorry for my unfinished work. I honestly never intended to abandon the project, and the reason I never said anything about leaving was because I was telling even myself “nah, I don't feel like it right now, but I'll be sure to continue working on avs+ in a month or so.” I guess it is safe to say now that this has been going on for so long, that who am I kidding?!

I guess partly the reason is that 1) my work on avisynth was strongly linked to my involvement in the fansubbing scene, which I stopped participating in about a year ago (we'll see if I'll be back now). Also, 2) I also got a bit demotivated due to some other reasons.

Anyway, pinterf seems to have done a splendid work on ironing out the most important rough edges. But most importantly, I am writing to offer my help. I doubt I'll be as active as before regarding coding, but reading back this thread, I have seen a few posts where I think I can be of help.

1) At some point it was mentioned it'd be good if somebody was around to answer questions about the current design, mostly relating to caches. It seems pinterf has since then figured out what he needed at that point, but still, if he has any questions, I'll be here.

2) He also mentioned he is keeping his changes on a different branch so that should it come to that, integration to Avs+ can be done easily. If he would like to, I'd be more than happy to pull his changes into the Avs+ repository. pinterf said somewhere something about a code review, I can do that too if he'd like to.

3) As an extension to the previous point, I'd like to give him full rights to the main Avs+ repository (I do not intend to monopolize on the development of Avs+, after all, maybe the most important goal of the whole fork was to try to revitalize the community).

4) I also see no problem in issuing an updated installer with the new improvements.

5) Am I back? To some small extent. I'd like to be an active member of the community, but realistically speaking new talents are needed to ensure active development. Please let us give pinterf and other interested people our support.

[Sparktank]

This is good news, Ultim! :goodpost:

Even if you will be scarce, it's great to hear continued interest.

[ryrynz]

Great news. Nice to see you back and what that'll mean for this project going forward.

I guess nows a good a time as any to ask if anyone here would be willing to put together a compatible 64 bit version of cretindesalpe's updated awarpsharp 2. I'm getting instability using the 2012 64 bit build and it's the only filter keeping me from a full 64 bit work flow, cheers.

[ultim]

Great news. Nice to see you back and what that'll mean for this project going forward.

I guess nows a good a time as any to ask if anyone here would be willing to put together a compatible 64 bit version of cretindesalpe's updated awarpsharp 2. I'm getting instability using the 2012 64 bit build and it's the only filter keeping me from a full 64 bit work flow, cheers.

Eh, that's assembly :p

TurboPascal has more than enough experience in doing such things (porting things over to much better intrinsics, which at the same time brings proper x64 support), but I think he lost interest in Avs.

Asking cannot hurt though.

[jackoneill]

Eh, that's assembly :p

TurboPascal has more than enough experience in doing such things (porting things over to much better intrinsics, which at the same time brings proper x64 support), but I think he lost interest in Avs.

Asking cannot hurt though.

I think you could copy them from the VapourSynth plugin.

[Reel.Deel]

I guess nows a good a time as any to ask if anyone here would be willing to put together a compatible 64 bit version of cretindesalpe's updated awarpsharp 2. I'm getting instability using the 2012 64 bit build and it's the only filter keeping me from a full 64 bit work flow, cheers.

Apparently this only happens with 64-bit ffdshow (http://forum.doom9.org/showthread.php?p=1769711#post1769711). I remember the SVP people also had troubles with 64-bit ffdshow. In the end it turned out to be an issue with ffdshow. Not saying that's the issue here, just something to keep in mind.

More info here: https://github.com/AviSynth/AviSynthPlus/issues/50

[ryrynz]

You know, that could quite well be it.. I don't hold much hope of anyone wanting to delve into ffdshow to fix this but if anyone is going to then I guess it would be either pinterf or ultim. I'll just continue to use the 32 bit version like I always have done for years no worries.

It would be nice to see if fixing the above issue resolves it, ffdshow is still required for real time processing and a full 64 bit chain should be more efficient. The crash occurs instantly on start up about 20% of the time. I am fairly certain that just a single basic awarpsharp call will trigger it, I'll confirm it and update this post later tonight, thanks.

[MysteryX]

The issue with SVP and ffdshow x64 doesn't cause a crash but is a serious memory leak that happens on every seek. It doesn't liberate its resources.

[ryrynz]

To be clear, the player (in this case mpc-be) crashes instantly. I'll pin point it down a bit better and play with a few options.