Avisynth+

[ultim]

My real question indeed, is : When i tried to recompile my filters, i have one which use "CACHE_25_RANGE". I guess remplacement should be "CACHE_GET_RANGE", but i want to be sure. Thanks.

The exact code is :

child->SetCacheHints(CACHE_25_RANGE,3);
.....
v.AsClip()->SetCacheHints(CACHE_25_RANGE,2);


No, that is actually the wrong fix. The old CACHE_25_* constants got removed by IanB. No plugin should use them anymore. For replacement, you can use one of the first four members of the CachePolicyHint enum. He has documented his new semantics in this post (http://forum.doom9.org/showthread.php?p=1595750#post1595750). According to his explanations, the correct replacement in your case should be CACHE_WINDOW, but please also read his post.

[ultim]

I think it was decided (for Avs+), that you should include $AVISYNTH_INSTALL_DIR/include to your project include directory inatead of copy them everywhere.

It is $(AVISYNTH_SDK_PATH)\include that should be in your project. And if you don't have Avisynth+'s FilterSDK installed, you can add the path that you manually copied the headers to.

While discussing this on the IRC just recently, it was noticed the installer isn't setting AVISYNTH_SDK_PATH at all. Something that slipped through the cracks. This will be fixed in the next installer on our side.

[jpsdr]

I think i'll keep what i've done. At least, i'm sure if someone get my project from github :
- He can compile it whatever avisynth version is installed.
- I'm sure it will compile with the same files as me, thing not sure with the way you describe.

Anyway, thanks for your return and these informations.

[innocenat]

It was also discussed that if each plugin keeps its own avisynth.h, when people are compiling it they need to know what version of avisynth.h it is: 2.5? 2.6-a3? 2.6a5? 2.6rc1? 2.6-64bit? Avs+? Even though Avs+ header is compatible with 2.6a5, 2.6rc1 and 2.6MT, in future if breaking change happen (like 2.6rc1 64bit interface), people who are recompiling your plugin need to manually look what version of avisynth.h you are using.

Though personally I also find bundling avisynth.h much easier

[jpsdr]

There is, from my point of view, no perfect solution. If people have 2.6rc1, if they build 64 bit version, compatibility is broken. If they have 2.5 installed or a too old 2.6, it will (or may) not compile at all...
After, personnal taste, i'm not big fan of "Getting my project is not enough, you have also to install X,Y,Z,W, etc... if you want to build it" (in fact, i realy don't like these kind of situations, but unfortunately sometimes it's realy unavoiable), this is why, i personnaly choose the "No need to install anything" solution package.
So, for me, both solutions have pro and cons. I choose what i personnaly prefer, because, i like less the other option.
After, i'm absolutely not trying to argue to change anything. Things have been explained, for valid reasons, it's totaly Ok for me.

[ultim]

I instrumented the script to report the processing of most lines via DbgView, see embedded code. This script ran several dozen times with 2.6 MT without fail in patched AvsPmod. After I lost patience today and installed Avisynth+ r1576, AvsPmod crashed in several runs and paused (maybe better term than freeze here) in all other runs, between line 124 and 125. Try {RT_Version()} catch (msg) {assert(false,"This script requires the RT_Stats plugin.")}
Try {GEval("")} catch (msg) {assert(false,"This script requires the GScript plugin.")}
global ofs=0

#============================================================================
Filename=RT_FSelSaveAs(title="Save Filter list",dir="",filt="Text files|*.txt",fn="_All+Functions_.txt",debug=true)
Assert(FileName.IsString(), "Please provide a file name to save the filter list")

#============================================================================
RT_WriteFile(Filename, VersionString(), Append=false) Try {assert(false)} catch(err) {Line(err,0)}
WriteInternalFunctionsSyntax(RT_InternalFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
WritePluginFunctionsSyntaxBackward(RT_PluginFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
WritePluginFunctionsSyntax(RT_PluginFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
WritePluginFunctionsSyntaxBackward(RT_PluginFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
WritePluginFunctionsSyntax(RT_PluginFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
WritePluginFunctionsSyntaxBackward(RT_PluginFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
WritePluginFunctionsSyntax(RT_PluginFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
WritePluginFunctionsSyntaxBackward(RT_PluginFunctions(), Filename) Try {assert(false)} catch(err) {Line(err,0)}
BlankClip().subtitle("Function info is complete.",align=5)

#============================================================================
function WriteInternalFunctionsSyntax(string fu_list, string Filename) {
Try {assert(false)} catch(err) {Line(err,0)}
GScript("""
done="" Try {assert(false)} catch(err) {Line(err,23)}
while(fu_list != "") {
i = FindStr(fu_list+" ", " ") Try {assert(false)} catch(err) {Line(err,23)}
fu_name = LeftStr(fu_list, i-1) Try {assert(false)} catch(err) {Line(err,23)}
fu_list = MidStr(fu_list, i+1) Try {assert(false)} catch(err) {Line(err,23)}
params = RT_PluginParam(fu_name) Try {assert(false)} catch(err) {Line(err,23)}
if (FindStr(done, fu_name+params)==0) {
done = done + " "+fu_name+params Try {assert(false)} catch(err) {Line(err,23)}
RT_WriteFile(Filename, "internal %s ( %s ) -> %s", fu_name, params, GetReturnType(fu_name, params), Append=true)
Try {assert(false)} catch(err) {Line(err,23)}
}
}
""")
}
#============================================================================
function WritePluginFunctionsSyntax(string fu_list, string Filename) {
Try {assert(false)} catch(err) {Line(err,0)}
GScript("""
done="" Try {assert(false)} catch(err) {Line(err,41)}
while(fu_list != "") {
i = FindStr(fu_list+" ", " ") Try {assert(false)} catch(err) {Line(err,41)}
fu_name = LeftStr(fu_list, i-1) Try {assert(false)} catch(err) {Line(err,41)}
fu_list = MidStr(fu_list, i+1) Try {assert(false)} catch(err) {Line(err,41)}
i = FindStr(fu_name, "_") Try {assert(false)} catch(err) {Line(err,41)}
if (i>0) {
params = RT_PluginParam(fu_name) Try {assert(false)} catch(err) {Line(err,41)}
if (FindStr(fu_list, "_"+fu_name)==0 && FindStr(done, "_"+fu_name+params)==0) {
done = done + " _"+fu_name+params Try {assert(false)} catch(err) {Line(err,41)}
RT_WriteFile(Filename, "plugin %s ( %s ) -> %s", fu_name, params, GetReturnType(fu_name, params), Append=true)
Try {assert(false)} catch(err) {Line(err,41)}
}
}
}
""")
}
#============================================================================
function WritePluginFunctionsSyntaxBackward(string fu_list, string Filename) {
Try {assert(false)} catch(err) {Line(err,0)}
GScript("""
done="" Try {assert(false)} catch(err) {Line(err,62)}
fu_list = RevStr(fu_list) Try {assert(false)} catch(err) {Line(err,62)}
while(fu_list != "") {
i = FindStr(fu_list+" ", " ") Try {assert(false)} catch(err) {Line(err,62)}
fu_name = RevStr(LeftStr(fu_list, i-1)) Try {assert(false)} catch(err) {Line(err,62)}
fu_list = MidStr(fu_list, i+1) Try {assert(false)} catch(err) {Line(err,62)}
i = FindStr(fu_name, "_") Try {assert(false)} catch(err) {Line(err,62)}
if (i>0) {
params = RT_PluginParam(fu_name) Try {assert(false)} catch(err) {Line(err,62)}
if (FindStr(fu_list, "_"+fu_name)==0 && FindStr(done, "_"+fu_name+params)==0) {
done = done + " _"+fu_name+params Try {assert(false)} catch(err) {Line(err,62)}
RT_WriteFile(Filename, "plugin %s ( %s ) -> %s", fu_name, params, GetReturnType(fu_name, params), Append=true)
Try {assert(false)} catch(err) {Line(err,62)}
}
}
}
""")
}
#============================================================================
#function GetReturnType(string fu, string params) { r = "?" }
#============================================================================
function GetReturnType(string fu, string params) {
Try {assert(false)} catch(err) {Line(err,0)}
GScript("""
RT_DebugF("Fu=%s %s", fu, params, name="GetReturnType") Try {assert(false)} catch(err) {Line(err,86)}
if (MidStr(fu,3,1)=="+") {fu = LeftStr(fu,2)+MidStr(fu,2) Try {assert(false)} catch(err) {Line(err,86)}}
if (MidStr(fu,2,1)=="+") {fu = LeftStr(fu,1)+fu Try {assert(false)} catch(err) {Line(err,86)}}
else if (fu=="Assert") {r = "conditional halt" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "avss_26_DSS2")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "ImageSeq_")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "LoadCPlugin")>0) {r = "void" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "LoadVirtualdubPlugin")>0) {r = "void" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "MDepan")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "MSCDetection")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "mvtools2_")>0) {r = "clip?" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "ResampleAudio")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "Resize")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "RT_Debug")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "RT_FSel")>0) {r = "." Try {assert(false)} catch(err) {Line(err,86)}}
else if (FindStr(fu, "Source")>0) {r = "clip" Try {assert(false)} catch(err) {Line(err,86)}}
else {
bc = BlankClip(width=8,height=8,length=1,pixel_type="YV12")
Try {assert(false)} catch(err) {Line(err,86)}
fp = LeftStr(params,2)=="cc" ? "(bc,bc)"
\ : LeftStr(params,2)=="cf" ? "(bc,0.1)"
\ : LeftStr(params,3)=="cci" ? "(bc,bc,0)"
\ : LeftStr(params,5)=="ciiii" ? "(bc,0,0,0,0)"
\ : LeftStr(params,4)=="ciii" ? "(bc,0,0,0)"
\ : LeftStr(params,3)=="cii" ? "(bc,0,0)"
\ : LeftStr(params,2)=="ci" ? "(bc,0)"
\ : LeftStr(params,1)=="c" ? "(bc)"
\ : LeftStr(params,2)=="ff" ? "(0.1,0.1)"
\ : LeftStr(params,1)=="f" ? "(0.1)"
\ : LeftStr(params,2)=="ii" ? "(0,0)"
\ : LeftStr(params,1)=="i" ? "(0)"
\ : LeftStr(params,2)=="ss" ? "("+chr(34)+"1"+chr(34)+","+chr(34)+"1"+chr(34)+")"
\ : LeftStr(params,2)=="si" ? "("+chr(34)+"1"+chr(34)+",1)"
\ : LeftStr(params,1)=="s" ? "("+chr(34)+"1"+chr(34)+")"
\ : "()" Try {assert(false)} catch(err) {Line(err,86)}
Try {
Try {assert(false)} catch(err) {Line(err,86)}
r = Eval("current_frame=0 "+fu+fp) Try {assert(false)} catch(err) {Line(err,86)}
r = r.IsBool ? "bool" : r.IsClip ? "clip" : r.IsInt ? "int" : r.IsFloat ? "float" : r.IsString ? "string" : "?"
Try {assert(false)} catch(err) {Line(err,86)}
} catch (msg) {
Try {
r = r.IsBool ? "bool" : r.IsClip ? "clip" : r.IsInt ? "int" : r.IsFloat ? "float" : r.IsString ? "string" : "?"
} catch(msg) {
r = "?" Try {assert(false)} catch(err) {Line(err,86)}
}
}
if (r=="?") {
bc = BlankClip(width=8,height=8,length=1,pixel_type="RGB32")
Try {assert(false)} catch(err) {Line(err,86)}
fp = LeftStr(params,2)=="cc" ? "(bc,bc)"
\ : LeftStr(params,2)=="cf" ? "(bc,0.1)"
\ : LeftStr(params,3)=="cci" ? "(bc,bc,0)"
\ : LeftStr(params,5)=="ciiii" ? "(bc,0,0,-0,-0)"
\ : LeftStr(params,4)=="ciii" ? "(bc,0,0,0)"
\ : LeftStr(params,3)=="cii" ? "(bc,0,0)"
\ : LeftStr(params,2)=="ci" ? "(bc,0)"
\ : "(bc)" Try {assert(false)} catch(err) {Line(err,86)}
Try {
Try {assert(false)} catch(err) {Line(err,86)}
r = Eval("current_frame=0 "+fu+fp) Try {assert(false)} catch(err) {Line(err,86)}
r = r.IsBool ? "bool" : r.IsClip ? "clip" : r.IsInt ? "int " : r.IsFloat ? "float" : r.IsString ? "string" : "?"
Try {assert(false)} catch(err) {Line(err,86)}
} catch (msg) {
r = "?" Try {assert(false)} catch(err) {Line(err,86)}
}
}
if (r=="?" && LeftStr(params,1)=="c") {r="clip?" Try {assert(false)} catch(err) {Line(err,86)}}
}
""")
Try {assert(false)} catch(err) {Line(err,0)}
return r
}
#=====================================================================================================================
function Line(string s, int ofs) {ofs=default(ofs,0) s=RightStr(s,FindStr(RevStr(s)," ")-1) s=LeftStr(s,StrLen(s)-1) l=int(value(s)+ofs) RT_DebugF("%d",l,name="@line ")}
#=====================================================================================================================

Script may look complicated first but is easy to understand I think. Best I can do today is provide this 'tool' to provoke the failure.
I do assume that the behavior is machine-dependent, since FFT plugins make it more prone to fail,
When reproducing, note that line numbers are logged after the command in that line.

Hi m53!

I've looked at what's happening in detail, and there are three different things going on.


TIVTC.dll cannot handle your clip with a size of 8 pixels. It is crashing in its hand-written assembly routines due to an access violation. This can be solved in your script by increasing the size of your BlankClip to at least 16 pixels.
Average.dll, DePan.dll, and mvtools2.dll are causing access violations all over the place, and multiple times in a single run. They pretty probably don't like the parameters your script is calling them with. This seems irrespective of the clip size they get. Once I've moved them out of my plugins directory (and increased the clip size to 16 for TIVTC), your script executed to the end without errors.
There also seems to be a memory leak that I haven't tracked down yet. This is not what is causing the crashes though, that's going to be the previous two points for almost sure.

Points 1-2 are obviously optimally fixed in the plugins. If no one is going to fix them, your script can at least work around point 1), and as for point 2)... well, you decide what's the best course of action. Note that you might also have additional plugins on your machine that I don't and are causing similar issues.

As for point 3), I'm still investigating it. It might be something inside AviSynth+. But due to your script calling all possible plugin functions and many plugins being buggy (see previous point) by not doing nearly enough parameter validations, this too might as well be a result of an erronous plugin. Even probably.

Anyway, the crash itself wasn't due to AviSynth+.

[martin53]

Ultim,
thank you for the detailed analysis! Especially that you took the time to assign the plugin crashes to the particular plugins. Be sure I estimate this right!
It is still worrying me that the same buggy plugins started from Avisynth 2.6 MT and Avisynth+ make the system as a whole react so differently. And more than the fact it reproduceably crashes after call of certain plugins - which I probably best can solve by explicitly checking in my script and provide a prepared return value - this extreme pausing is weird.
Can Avisynth+ itself do anything more to control/manage plugin crashes even better than now?

[Groucho2004]

Ultim,
thank you for the detailed analysis! Especially that you took the time to assign the plugin crashes to the particular plugins. Be sure I estimate this right!
It is still worrying me that the same buggy plugins started from Avisynth 2.6 MT and Avisynth+ make the system as a whole react so differently. And more than the fact it reproduceably crashes after call of certain plugins - which I probably best can solve by explicitly checking in my script and provide a prepared return value - this extreme pausing is weird.
Can Avisynth+ itself do anything more to control/manage plugin crashes even better than now?
You should also consider that there are DLLs that are needed for some plugins that cause havoc by just loitering in the auto-load directory. Do a search for "AVSFilterNet.dll", for example.

[ultim]

Ultim,
thank you for the detailed analysis! Especially that you took the time to assign the plugin crashes to the particular plugins. Be sure I estimate this right!
It is still worrying me that the same buggy plugins started from Avisynth 2.6 MT and Avisynth+ make the system as a whole react so differently. And more than the fact it reproduceably crashes after call of certain plugins - which I probably best can solve by explicitly checking in my script and provide a prepared return value - this extreme pausing is weird.
Can Avisynth+ itself do anything more to control/manage plugin crashes even better than now?

By the nature of access violations, they will have different effects based on what code is loaded, how much memory was allocated and in what order, what is stored in the memory etc. The point in time where the OS starts screaming about these errors is typically just the tip of the iceberg, and there's a really good chance that memory got corrupted a lot earlier than that. Not every memory corruption manifests itself as an access violation error: when that happens, it merely means - in laymen terms - that the corruption has spread so much that even the OS recognized it. If a video encoding process doesn't crash (which is by pure chance) when an access violation happens in a plugin, that's worse than crashing, because then most probably your encode will be corrupted, and you won't notice it.

All the above means that trying to recover from an access violation is pretty much the worst thing you can do. It might seem odd for a user, but in such a case it really is best practice to just terminate loudly, as soon and fast as you can. Any attempt to recover might make things much worse. Hiding it won't do you any good, because even though you can hide it from the user, it is impossible to negate the corruption it has caused.

My point is: If a plugin is crashing due to an access violation, I'm glad if the whole process crashes. You should be too. I certainly won't try to manage it any "better". I am already performing sub-optimal by turning it into a C++ exception, but that is to have similar behavior to AviSynth 2.6.

[martin53]

Maybe it's not worth to put toooo much work into dealing with touchy plugins.

Why did I write this odd script? Because for writing on the Avisynth+ documentation pages I was just interested in an inventory of all available functions (unrecognized plugin funcs too, out of pure curiosity), and if they were clip or non-clip functions.
Maybe there is a much better way for that than this dumb script?

Of course once the script was in the world, I was also unsettled by the more obvious malfunction in combination with Avisynth+. Yet I agree that malfunctions should either be contained properly, and if they can't - which will sure be mostly the case with access violations - a hidden damage is no better than an obvious one.

[ultim]

Okay, things are starting to shape up. Reported bugs have all been looked at, where appropriate fixed, and MT-functionality has also seen some necessary correctness improvements. I'm thinking about releasing 0.2 pretty soon. What is needed for that at this point is mainly testing, and maybe getting some additional content for the installer into shape. The more adventurous among you can pull the latest test binaries from avs-plus.net/builds (http://avs-plus.net/builds). Starting now, binaries are built with a newer C++ runtime due to the wide availability of VS Community Edition, so if you feel like testing, don't forget to also get the vcredist stuff under the same link. In the official release, the installer will take care of setting up the runtime for you of course.

Depending on what you testers report, the r1779 binaries might be extremely similar to what 0.2 will be. I, for one have been using recent builds in my own production encodes without problems, and the (very few) independent testers I gave them to also had encouraging reports.

As for what the new caching system coupled with the rewritten filters in AviSynth+ are capable of, I'm also showing you these results (http://pastebin.com/7k4KNrAk), based on a real-world and pretty heavy script. And it was running only single-threaded. Now these measurements are not to be generalized, and results will surely depend on both your machine as well your script, but I certainly started smiling when I first saw this comparison. Do you like it? Are you excited for AviSynth+ 0.2?

EDIT: "Quite few" came out wrong upon reading it over. What I mean to say is very few testers, not "quite a few".
EDIT: I forgot to mention, the way how you specify the default MT mode for all filters that don't have it set explicitly has changed. For that, the first argument of SetFilterMTMode now has to be "DEFAULT_MT_MODE" instead of just "" (an empty string). I updated the MT usage notes (http://forum.doom9.org/showthread.php?p=1666371#post1666371), please consult them about how to use MT.

[ultim]

chainik_svp,
you should also try out the latest build linked above. while i cannot stop ffdshow from leaking, this build should have improved the situation a lot. i also briefly looked at ffdshow's avisynth bridge, and i think i saw what the problem is. if you can get me someone who can build ffdshow for a test, i could submit a patch to try and see.

[LoRd_MuldeR]

if you can get me someone who can build ffdshow for a test, i could submit a patch to try and see.

You could try to bother clsid (https://forum.doom9.org/member.php?u=71929) ;)

[chainik_svp]

ultim
Are you excited for AviSynth+ 0.2?

I'd be extremely excited IF the release will contain MT functions.
I mean make MT-enabled version the one and only version for AVS+.


you should also try out the latest build linked above

I will, thanks!


if you can get me someone who can build ffdshow for a test, i could submit a patch to try and see.

yeah, clsid is the one :)

[ultim]

ultim
Are you excited for AviSynth+ 0.2?

I'd be extremely excited IF the release will contain MT functions.
I mean make MT-enabled version the one and only version for AVS+.

The build has all the MT functions. AVS+ won't have non-MT builds anymore. Due to the relatively new nature of MT in Avs+ though, MT-enabled encodes possibly don't yet have the same maturity as non-MT encodes with the same binary. This immaturity is exactly what testing should dissolve over time.

[Groucho2004]

The more adventurous among you can pull the latest test binaries from avs-plus.net/builds (http://avs-plus.net/builds).
One potential problem with that build (x86):
I'm using this script to make avisynth run out of memory:
setmemorymax(3000)
n = 4800
colorbars(width = n * 2, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001).trim(0, 999)
SelectRangeEvery(1000, 100, 200)
temporalsoften(4,4,8,15,2)
pointresize(width() - 64, height() - 64).turnleft()
temporalsoften(4,4,8,15,2)
pointresize(width() + 64, height() + 64).turnright()
temporalsoften(4,4,8,15,2)

With the "official" 2.6 I get the usual "We've run out of memory, folks" message after 9 frames.
With AVS+ r1718 I get "Could not allocate video frame. Out of memory." after 4 frames.
AVS+ r1778 does not get past the first frame but also throws "Could not allocate video frame. Out of memory.". However, it also crashes with c0000005 (access violation). Crash dump is here (http://pastebin.com/RNaMwJJD).

[chainik_svp]

In fact I'd LOVE to replace Avisynth with AVS+ in SVP distribution.

We're just waiting for the "official" MT build (32-bit).
And we're all looking forward for the stable 64-bit version.

ultim, if you've any other thoughts about bundling AVS+ with SVP - please contact me :)


AVS+ won't have non-MT builds anymore.

good news, everyone :D

[sl1pkn07]

please keep the non-MT version (the lastest one), for if the linux users are unable to run the MT version

[Groucho2004]

Actually, r1778 crashes with every script. I'm on WinXPSP3.

[chainik_svp]

sl1pkn07

> linux users are unable to run the MT version

Why? o_O

And since AVS+ is by design Windows-only, why won't Linux users switch to native Vapoursynth?

[chainik_svp]

actually, r1778 crashes with every script. I'm on winxpsp3.

vc++ 2013 rt? :)

[Groucho2004]

vc++ 2013 rt? :)
-----Yes.

[innocenat]

sl1pkn07

> linux users are unable to run the MT version

Why? o_O

And since AVS+ is by design Windows-only, why won't Linux users switch to native Vapoursynth?

Wine C++ runtime did not support #include <thread> used by Avs+ MT iirc. But I thought it was already fixed?

[chainik_svp]

may be binaries was built with v120 instead of v120_xp?

> Wine C++ runtime did not support #include <thread> used by Avs+ MT iirc.

so this's the question to WineHQ, right?

and last time I checked, I was able to install any VC runtime i needed
VC runtime isn't provided by Wine o_O

[Groucho2004]

may be binaries was built with v120 instead of v120_xp?
Then it should not run at all (I think).

[sl1pkn07]

sl1pkn07

> linux users are unable to run the MT version

Why? o_O

And since AVS+ is by design Windows-only, why won't Linux users switch to native Vapoursynth?

i mean, maintain the both version, the last one non-MT and the MT version

yes, i use a VS, but for some projects needs maintain AVS system

greetings

[innocenat]

may be binaries was built with v120 instead of v120_xp?

> Wine C++ runtime did not support #include <thread> used by Avs+ MT iirc.

so this's the question to WineHQ, right?

and last time I checked, I was able to install any VC runtime i needed
VC runtime isn't provided by Wine o_O

A year ago (that was when this wine and thread thing was discussed here, and I dont follow wine development much) the situation is that some api arent available so even if you install vcredist it wont run thread at all. And that bug was assigned WontFix in wine bug tracker.

So if that bug is still present, user kinda require ST version.

[qyot27]

The issues with Wine are gone (http://forum.doom9.org/showthread.php?p=1707414#post1707414) so long as you're using the latest Wine 1.7, although the native Wine dlls for msvc[p|r]120 are still insufficient, so you need the MS ones (since 1.7 is the -devel branch, this could very well change before 1.8). My various personal builds of AviSynth+ from r1718 onwards seem to work fine - I get similar speeds as I was with 2.6 MT (might be mostly due to getting bottlenecked in HCenc). And I was using Prefetch(4) and setting the filter mode with the .avsi, so the MT should be active.

The only problem is that the MSVC 2012 and 2013 runtime installers error out. The DLLs work, the installers don't. So trying to use the redist bundled in AviSynth+'s installer won't work on Wine. You have to extract the dlls from the MS redists and copy them into Wine's system32 directory, and then add overrides for those DLLs in winecfg. This was true on both OSX 10.10 with Homebrew and Ubuntu 14.10 with the ubuntu-wine PPA. Really, winetricks is the place to handle that part, and it should be only a matter of time before vcrun2012/vcrun2013/etc. options get added to it (if they haven't been already).

And since AVS+ is by design Windows-only,
Classic AviSynth has that limitation; there is work being done to resolve that issue in AviSynth+ (it's just taking a while).

[ultim]

One potential problem with that build (x86):
I'm using this script to make avisynth run out of memory:
setmemorymax(3000)
n = 4800
colorbars(width = n * 2, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001).trim(0, 999)
SelectRangeEvery(1000, 100, 200)
temporalsoften(4,4,8,15,2)
pointresize(width() - 64, height() - 64).turnleft()
temporalsoften(4,4,8,15,2)
pointresize(width() + 64, height() + 64).turnright()
temporalsoften(4,4,8,15,2)
...

Yeah this script runs out of memory. I'll try to adapt some things to shrink the caches more aggressively under extreme memory pressure.

As for XP-compatibility, all things are compiled with the xp-toolset, so at least from that aspect, it should be fine. I wonder if there was some other oversight on my part (e.g. using an unsupported API or dunno what), I admit I haven't tested on XP at all. Will look into it.

[Boulder]

It's been a year since I said "I'm going to hop on from Avisynth MT (SEt's latest v2.6 build) to Avisynth+ just for some testing." and now it seems that it is the time if you feel that the multithreading issues should be gone. Do you have anything specific you wish to have tested? Should the output of Avisynth 2.6 MT and Avisynth+ be identical? And the most important question: is MT enabled automatically or does it need to be set to achieve maximum performance?

[chainik_svp]

MT is not working for me in the latest build o_O
The very same script

global threads=9
SetFilterMTMode("",2)
SetFilterMTMode("ffdShow_source",3)
ffdShow_source()
...
Prefetch(threads)
is working as expected with October build and working with a 1-thread speed with the latest one

[ultim]

and now it seems that it is the time if you feel that the multithreading issues should be gone.
At least the ones that I know of. Whether there is anything else undiscovered, we will find out as more and more people test. So yes, now is the right time to test again.

Do you have anything specific you wish to have tested?
Nothing really in specific. Just use your regular scripts as you would normally do, and let me know if you see any problems. Plus-points for anybody who also tries out their script(s) using MT, but for that be sure that the correct filter modes have been specified. I cannot stress this enough: you can only expect MT-mode to behave sanely if you have the correct MT mode setting for all filters in your script.
Here is a start for MT mode settings: https://pad.riseup.net/p/avs_plus_mt_modes . Never-fading fame for all who make fixes or additions to that list.

Should the output of Avisynth 2.6 MT and Avisynth+ be identical?
The output should be visually indifferentiable, but not bit-exact identical.

And the most important question: is MT enabled automatically or does it need to be set to achieve maximum performance?
It needs to be set up in your script. Not just for maximum performance, but also for correct operation in general. The setup is composed of two parts: 1) Setting the MT modes in the beginning, then 2) enabling MT by adding the Prefetch-line to the end of your script. For detailed instructions (including example) about using MT, see this post (http://forum.doom9.org/showthread.php?p=1666371#post1666371).

[ultim]

MT is not working for me in the latest build o_O
The very same script

global threads=9
SetFilterMTMode("",2)
SetFilterMTMode("ffdShow_source",3)
ffdShow_source()
...
Prefetch(threads)
is working as expected with October build and working with a 1-thread speed with the latest one

Hi,
Replace
SetFilterMTMode("",2)
by
SetFilterMTMode("DEFAULT_MT_MODE",2)

Sorry I forgot to mention earlier.

[Boulder]

@ultim: Thanks a lot, I'll try to find the time to experiment this week :)

[Groucho2004]

Yeah this script runs out of memory. I'll try to adapt some things to shrink the caches more aggressively under extreme memory pressure.

As for XP-compatibility, all things are compiled with the xp-toolset, so at least from that aspect, it should be fine. I wonder if there was some other oversight on my part (e.g. using an unsupported API or dunno what), I admit I haven't tested on XP at all. Will look into it.
As I mentioned later, r1778 crashes with every script on my WinXP.

[burfadel]

As I mentioned later, r1778 crashes with every script on my WinXP.

Windows XP.

Compiling for Windows XP and making it universal is detrimental to users of Windows 8.1 etc.

[chainik_svp]

SetFilterMTMode("DEFAULT_MT_MODE",2)

Yeah, thanks.

I see some very strange behavior when playing video with SVP.
Everything looks great, except when I set number of threads to 6 or 11 video playback becomes choppy.
Every other number (tested values from 2 to 15) gives smooth playback.
I'm on 2 cores / 4 threads SandyBridge now. Will test it with my FX-8320 later...

===
it looks like source filter (which is ffdshow_source()) became inaccurate with those values
i.e. the next filter in the chain (SVSuper()) sometimes receives the same frame when it asks for N and N-1
so motions vectors are zero and playback is choppy

most likely this's some issue with the cache

[Groucho2004]

Windows XP.

Compiling for Windows XP and making it universal is detrimental to users of Windows 8.1 etc.
- Can you share any examples from your development experience that would support such a generalized statement?
- Do you work for Microsoft?
- Just trolling?

[ultim]

it looks like source filter (which is ffdshow_source()) became inaccurate with those values
i.e. the next filter in the chain (SVSuper()) sometimes receives the same frame when it asks for N and N-1
so motions vectors are zero and playback is choppy

most likely this's some issue with the cache

Hmmm, I'm not sure about that. Might as well be just DirectShow messing up, as it is known to be not frame-accurate during seeks in general. This is often not a problem during sequential processing, but with MT-mode enabled, directshow will recieve out-of-order frame requests even during sequential playback.

Edit: Consideirng that in your case avisynth is not running as a standalone directshow filter but as part of ffdshow, it might actually be frame-accurate depending on which source filters ffdshow chooses to use. I don't know enough about ffdshow internals to judge that tbh.

[chainik_svp]

I never saw this before with Avisynth ;)
And again, in AVS+ the issue is only with 6 or 11 threads. Some kind of magic numbers o_O

[ultim]

Windows XP.

Compiling for Windows XP and making it universal is detrimental to users of Windows 8.1 etc.

Don't worry burfadel, support for XP in AviSynth(+) does not have any negative effects that I can think of on post-XP Windows users.

[mark0077]

SetFilterMTMode("DEFAULT_MT_MODE",2)

Yeah, thanks.

I see some very strange behavior when playing video with SVP.
Everything looks great, except when I set number of threads to 6 or 11 video playback becomes choppy.
Every other number (tested values from 2 to 15) gives smooth playback.
I'm on 2 cores / 4 threads SandyBridge now. Will test it with my FX-8320 later...

===
it looks like source filter (which is ffdshow_source()) became inaccurate with those values
i.e. the next filter in the chain (SVSuper()) sometimes receives the same frame when it asks for N and N-1
so motions vectors are zero and playback is choppy

most likely this's some issue with the cache

With normal Avisynth MT I always have strange issues with audio going out of sync depending on what number of buffer aheads I use. See my previous posts at the thread below. The issue is still there for me, I again have to pick some "magic" good numbers of buffer ahead like 14 or 15 to stop audio going out of sync. (I'll try today with avisynth+ to see can I get audio to go out of sync).

http://www.svp-team.com/forum/viewtopic.php?id=1011&p=3

I definitely feel there's some work needed in the buffer ahead areas to stop choppyness and also audio going out of sync. I'm not sure whats the best way to illustrate this so that a solution could be found.

[ultim]

Hmmm, I'm not sure about that. Might as well be just DirectShow messing up, as it is known to be not frame-accurate during seeks in general. This is often not a problem during sequential processing, but with MT-mode enabled, directshow will recieve out-of-order frame requests even during sequential playback.

Another possible cause of choppy real-time playback is when threads gang up (e.g. their results arrive in "waves"). In that case they still deliver the same performance on average, but not evenly distributed in every short time window. To see if this is the case, you'd have to encode a piece of video to file with all the processing, then play back the pre-processed file without avisynth. If the playback is only choppy during real-time processing but not in the encoded file itself, this is exactly what is happening.

[mark0077]

I am having problems with audio desync when switching to avisynth+ (r1778) with SVP. I assume its down to the issue with ffdshow buffer ahead weirdness? Can anyone suggest a good number of avisynth+ threads, SVP cores, and ffdshow buffer aheads to try? I'm using core i7 920.

I was previously using SETs lates Avisynth MT with its threads, SVP cores and ffdshow buffer ahead set to a value of 15 where all worked fine. So far I have tried lowering the Avisynth+ threads down to 8 / 6 / 4 but audio seems really badly out of sync AND/OR video being choppy in all combinations I have tried.

[chainik_svp]

utim

This is not about timing, frames are rendering uniformly.
I can visualize motion vectors, and it's clear that they're all zeroes at some frames.
Zero-sized MVs mean source frames used for motion estimation was identical.

But I still can't reproduce this effect via avs2avi or figure out any simple test scenario for ffdshow o_O

May be you want to install SVP? :)

[ultim]

But I still can't reproduce this effect via avs2avi or figure out any simple test scenario for ffdshow o_O
Does that mean it only happens with ffdshow?

[burfadel]

Don't worry burfadel, support for XP in AviSynth(+) does not have any negative effects that I can think of on post-XP Windows users.

Ah ok. Still, I don't believe support should be in place for XP any more, it only encourages people to stick with it longer.

[chainik_svp]

I've checked frames returned by ffdshow_source() by inserting some debug code into Cache::GetFrame that computes 'checksum' of the Y plane.

Normal behavior (num of threads !=6): lookup always returns LRU_LOOKUP_NOT_FOUND, and for each 'n' returned frame is a new one (with contents different from frame 'n-1').

81: .... 8B35E6F
82: .... 8A80C08
83: .... 899A3CA
84: .... 89D3DED
85: .... 8B1A39A

Invalid behavior (num of threads ==6): every other frame is equal to the previous one.

81: .... 8B35E6F
82: .... 8B35E6F
83: .... 899A3CA
84: .... 899A3CA
85: .... 8B1A39A
86: .... 8B1A39A

[ultim]

I've checked frames returned by ffdshow_source() by inserting some debug code into Cache::GetFrame that computes 'checksum' of the Y plane.

Normal behavior (num of threads !=6): lookup always returns LRU_LOOKUP_NOT_FOUND, and for each 'n' returned frame is a new one (with contents different from frame 'n-1').

81: .... 8B35E6F
82: .... 8A80C08
83: .... 899A3CA
84: .... 89D3DED
85: .... 8B1A39A

Invalid behavior (num of threads ==6): every other frame is equal to the previous one.

81: .... 8B35E6F
82: .... 8B35E6F
83: .... 899A3CA
84: .... 899A3CA
85: .... 8B1A39A
86: .... 8B1A39A

I'll see if I can reproduce this.

[chainik_svp]

The very same magic numbers (6 and 11) on 4 cores / 8 threads AMD FX-8320