Avisynth+

[qyot27]

I'm getting a bit more performance with the same settings in avs+, so it made me think that maybe the plugins/filters aren't working properly.
What? This is right there in the list of features for avsplus:
Changes compared to AviSynth

64-bit version available
Faster script startup and substantially faster core filters
Support for multiple ("shadow") plugin directories
Autoloading of C-plugins
Script language extensions, with support for multiline conditionals and loops.
Improved still image support and TimeStretch
Justifiably, anything that depends on those core filters would get a boost too. To say nothing of the cache changes if you're using r1689 or higher.


Not to mention that a few of those filters have rewritten versions with avsplus in mind, and you'd get better (and probably more accurate, or at least just as accurate) results from using FFMS2 or LSMASHSource as your source filter, at the very least because those can use current builds of libavcodec, and libavcodec has most certainly gotten faster at decoding H.264 over the last 5 years since the last public release of DGAVCDec.

[TurboPascal7]

Thanks.
Nope, Layer doesn't work there either. This is the reason I used Overlay in the first place, couldn't figure out how to get Layer to work so I switched. Turns out the fault wasn't mine =).
Is it avs+-specific bug or do you experience the same problem with regular avs 2.6?

[ajp_anton]

avs+ specific. 2.6 works perfectly as soon as I replace avisynth.dll.

[TurboPascal7]

avs+ specific. 2.6 works perfectly as soon as I replace avisynth.dll.
Then please do provide an example script.

[ajp_anton]

Already did:m = colorbars
c = blankclip(m,color=$808080)
o = blankclip(m,color=$ff0000)

o = mask(o,m)

layer(c,o)
#o.showalpha #to see that the mask is indeed thereColorbars just to create some non-uniform mask, and use it to overlay uniform red into uniform grey.

[TurboPascal7]

Fixed (https://github.com/AviSynth/AviSynthPlus/pull/42). Thanks for the report.

[ajp_anton]

Is there any reason for r1689 to use more memory than r1576? (single-threaded)
This might be crazy, but I use Avisynth to generate a very large image full of data (both text and some simple graphics) that needs updating every day. r1689 crashes when I make it too large, r1576 doesn't.
Script is very long and includes some sensitive information. I could modify it slightly and send via PM if needed.

[vcmohan]

At the outset I request you all to make allowance to my limited knowledge of C++ programming.
I have read a number of posts starting from http://forum.doom9.org/showthread.php?p=1651085#post1651085 on multithreading and plugin compatibilities. I could not get a clear view of whether a plugin developer should in someway inform Avisynth+ whether it is MT compatible (if so in what way), or 'user' need to inform in his script. At someplace it was also mentioned that C++ interface is inferior to C interface.

I also read that for the present plugin developers may stick to Avisynth 2.6 plugin development, as Avisynth+ interface is likely to change.

I appreciate that this work is in progress and so is avisynth 2.6 alpha. However instead of compatibility for all versions, plugin developers (who are interested) may be guided as to which features they need to have to be compatible to the new avisynth+ or 2.6.

I will be grateful if all such instructions be mentioned and periodically updated either in a seperate thread or at the beginning of this thread.

[innocenat]

At the outset I request you all to make allowance to my limited knowledge of C++ programming.
I have read a number of posts starting from http://forum.doom9.org/showthread.php?p=1651085#post1651085 on multithreading and plugin compatibilities. I could not get a clear view of whether a plugin developer should in someway inform Avisynth+ whether it is MT compatible (if so in what way), or 'user' need to inform in his script. At someplace it was also mentioned that C++ interface is inferior to C interface.

I also read that for the present plugin developers may stick to Avisynth 2.6 plugin development, as Avisynth+ interface is likely to change.

I appreciate that this work is in progress and so is avisynth 2.6 alpha. However instead of compatibility for all versions, plugin developers (who are interested) may be guided as to which features they need to have to be compatible to the new avisynth+ or 2.6.

I will be grateful if all such instructions be mentioned and periodically updated either in a seperate thread or at the beginning of this thread.

The current MT version of Avisynth+ is still in development and is only for testing purposes. Thus, it is not (and should not) really be officially documented in the beginning of this thread.

As for the plugin, plugin author should inform the Avs+ core of its preferred operating mode (and the API is Avs2.6-compatible). However, while current API for this is are not likely to change, it is still not guaranteed to not be changed in final stable version of Avs+.

Avs+ fully support plugin written in 2.6 api (and if it isn't, it's a bug). For now it is recommended that you stick to original 2.6 API. There are currently extended API in the development version of avs+ core, but as I said, it is still not stable and should not be used by plugin as there are no compatibility guarantee between each testing revision. Furthermore, usage of those API will make your plugin not compatible with original Avs2.6.

Hope this helps.

[turbojet]

I noticed resizers were worked on 2 months ago. Are there any mt builds around that includes this?

[innocenat]

I noticed resizers were worked on 2 months ago. Are there any mt builds around that includes this?

You should be able to find one in https://mega.co.nz/#F!ZEtEELLB!DovfKg-0imp8R9JlasCzzQ Note that MT build is experimental.

[turbojet]

1689 has the fixes (https://github.com/AviSynth/AviSynthPlus/pull/27)? That's the same one Groucho and I tested that was about 2% slower with lanczos and spline.

The dll's version is 2.6.0.5 can that change to revision number in the future?

[innocenat]

1689 has the fixes (https://github.com/AviSynth/AviSynthPlus/pull/27)? That's the same one Groucho and I tested that was about 2% slower with lanczos and spline.

The dll's version is 2.6.0.5 can that change to revision number in the future?

Yes. r1689 should already have that fixes. Admittedly, I don't have any AMD to test on, so I don't know prior to your tests whether it is faster or slower on AMD's CPU. I do have a few more idea to optimize the resizer, but I haven't got around to do it yet.

[turbojet]

Ok, I was getting excited about something I already had then. The performance difference is about the same on Groucho2004's intel then it is on my amd. Bicubic is a lot faster maybe there's something in those that can improve lanczos, spline, bilinear, others haven't been tested.

[turbojet]

The riseup pad (https://pad.riseup.net/p/gfyPtMbihf6q) has been deleted. Is there another source for the mtmode avsi?

Might be nice to have it on the main site or original post of this thread.

[TurboPascal7]

I dunno where you got that link but it's wrong. Here's the right one (https://pad.riseup.net/p/avs_plus_mt_modes).

[turbojet]

Thanks, it was the from the first post after searching this thread for 'pad' but it was for installer translation. I should have paid more attention.
Some questions about mt:
1. Is an avsi the plan going forward with MT modes?
2. If so is there plans on having some sort of an update to a moderated avsi, or maybe included in new versions?
3. Is defining it inside the dll a lot of work?
4. Is there any thoughts on making mt opt-out instead of opt-in after it's stable? It seems to work fine so far for me, it often doesn't speed it up but it doesn't have any noticeable disadvantages either.

[cretindesalpes]

Hi,

This is probably related to this bug (http://forum.doom9.org/showthread.php?p=1669861#post1669861).

FFVideoSource ("bad-stack16.mkv", enable10bithack=true)
Video sample (12 MB) (http://www.mediafire.com/download/r4hfullc4tsy6da/bad-stack16.mkv)
Tested with Avisynth+ MT r1689 and FFMS2 r734-libav patched by SAPikachu.
Chroma planes have a wrong pitch. Happens only in stack16 mode. Everything works correctly in Avisynth 2.6 alpha 5.

[aegisofrime]

Hi, this thread has been pretty quiet lately. :( How's the progress on the MT version?

[Jeroi]

Does this project be active, github states that nothing happened in few months...? I would really like the features that this project aims expecially the directshow api support.

[TurboPascal7]

I myself lost interest in avisynth development (maybe temporarily) and all other people are a bit busy with other things right now. But ultim should be "back" some time soon, hopefully.
So no, right now the project obviously isn't "active".

[nickintheforest]

MT-enabled AviSynth+ triggers a latent bug in AvsPmod. Until a new version of AvsPmod is officially released, use this (http://www46.zippyshare.com/v/29821586/file.html) build. A thousand thanks to vdcrim for the fix.

Can anybody reupload that build?

Reel.Deel
thanks

[Reel.Deel]

@nickintheforest

Here's an active link:

AvsPmod-2.5.1-r426-x86-04874ed.7z (http://files.line0.in/builds/AvsPmod-2.5.1-r426-x86-04874ed.7z)

[real.finder]

Waiting for your return, especially ultim
I hope this calmness will be the calm before the storm

[zerowalker]

TurboPascal7,

If you find the interest, i would like to request ImageSource to be upgraded to support .Webp.

Probably alone in this, but might as well mention it if you happen to have any interest in it;P

[Jeroi]

Avisynth+ does not seem to be the future atm, not much development going, even Avisynth is getting more development these days...

[ryrynz]

That benefits Avisynth+ too.. hopefully a stable MT build later this year.

[aldix]

Dunno... using avisynth+ MT atm without serious issues...

[aegisofrime]

It seems like the alternative Avisynth developments are cursed... Anybody remember JoshyD's Avisynth 64 builds? Things were going great for a while, and he also ported many filters to 64-bit. Then he disappeared...

I hope the same isn't happening to ultim :scared:

[jpsdr]

Anybody remember JoshyD's Avisynth 64 builds?
Yes i remember.
But not all are cursed. Even if i don't use it, i think Set MT version is still alive, no ?

[StainlessS]

Is there a suggested alternative download link for A+, tried about 6 times to download, get an
"Invalid user name or password, or Access Denied" error message half way though.

EDIT: The installer.

[Groucho2004]

Is there a suggested alternative download link for A+, tried about 6 times to download, get an
"Invalid user name or password, or Access Denied" error message half way though.

EDIT: The installer.
Weird, works for me.

[ARDA]

Is there a suggested alternative download link for A+, tried about 6 times to download, get an
"Invalid user name or password, or Access Denied" error message half way though.

Just guessing, maybe you are logged in github

This is a direct link , it is working ok for me
https://github.com/AviSynth/AviSynthPlus/releases/download/Rel-r1576/AviSynthPlus-r1576.exe

if you don`t succeed, use this alternative of my own
https://mega.co.nz/#!REFXDTZb!g9LgEVXHSf92dvhZm5ksOIfDlcry8VPOwo2rbaH0mxA

[StainlessS]

Thank you Arda, I finally got it from 1st link (am not member on GitHub, so not signed in).
Thought I might finally give this a whirl, as the captain seems to have jumped ship, might be wise to unlash the life boats.

[Groucho2004]

Thought I might finally give this a whirl
There are some API differences in AVS+, one of which I stumbled upon a couple of days ago when I added the enumeration of plugin functions in the Avisynth Info Tool. The global variable "$PluginFunctions$" was removed because of the way AVS+ handles plugins. I believe you also use this variable in your RT_Stats code.

[StainlessS]

Goucho, I read somewhere that $PluginFunctions$ was being put back in, probably because of my use of it.

A bit later ... just checked my RT_Stats functions listing script, works just fine.

[Groucho2004]

just checked my RT_Stats functions listing script, works just fine.
Yes, but only after loading a script and initializing the plugin API.

Edit: Ha, I think I can trick it with a dummy call to "Invoke("LoadPLugin",...)". This way I don't have to load a script to get the external functions. :sly:

[StainlessS]

Ah,well, I only know it from the plugin side, if what I said makes sense to you and gave clue to a
workaround, that's great. Peace Bro.

[StainlessS]

Thank you Grouchy, I posted a script recently to give functions contained in an autoload only (from plugins dir) dll,
your Inkoke thing would probably (I think) also fix the issue I had. You are such a clever little lad :)
EDIT: This post: http://forum.doom9.org/showthread.php?p=1681523#post1681523

EDIT: I did try LoadPlugiin("PlugName.dll") but did not work, think you might need to know the name of a function/filter
and call it, to force it into existence (and of course if you knew names of functions, you would not be searching for them).

[zerowalker]

Is the MT working with smdegrain, if so is there any special settings/modes that needs to be used?

Thanks

EDIT:



SetFilterMTMode("FFT3Dgpu", 3)
SetFilterMTMode("", 2)

Avisource("Z:\Test.avi")
ConvertToYV12(matrix="Rec601", interlaced=false)

FFT3Dgpu(sigma=1.5, plane=3)

smdegrain(tr=3,lsb=true,thsad=300,lsb_out=true,search=3,refinemotion=true)
Dither_convey_yuv4xxp16_on_yvxx()
Prefetch(4)


I am guessing this should work from reading around, but not entirely sure.

[StainlessS]

Bump, dont miss last edit in my previous post Grouchy.

[Groucho2004]

I did try LoadPlugiin("PlugName.dll") but did not work, think you might need to know the name of a function/filter
and call it, to force it into existence (and of course if you knew names of functions, you would not be searching for them).
I'm doing this to force the invokation of "LoadPlugin":
try
{
AVSValue foo = AVS_env->Invoke("LoadPlugin", 0);
}
catch (AvisynthError e)
{
}
catch (...)
{
}



I'm not sure any more if we're talking about the same thing. You seem to be referring to scripting.

[Evil_Burrito]

Is the MT working with smdegrain, if so is there any special settings/modes that needs to be used? ...

SetFilterMTMode("FFT3Dgpu", 3)
SetFilterMTMode("", 2)
Avisource("Z:\Test.avi")
ConvertToYV12(matrix="Rec601", interlaced=false)
FFT3Dgpu(sigma=1.5, plane=3)
smdegrain(tr=3,lsb=true,thsad=300,lsb_out=true,search=3,refinemotion=true)
Dither_convey_yuv4xxp16_on_yvxx()
Prefetch(4)


I am guessing this should work from reading around, but not entirely sure.

Yes it will run, but mt scripts are not written the same way as using SEt's mt modes. Line 2 SetFilterMTMode("", 2) does not do anything because you didn't specify a filter inside "blank". Although, I myself do not 100% understand how to use the new avisynth+ mt, I do know that you have to specify the mode for each filter (excluding the core filters (and maybe a couple new filters specifically written for avisynth+?))
-----------------------
I have been meaning to ask a couple questions for months. Responders please don't lazy half answer my questions by just linking to an older post from this thread. I have been keeping up with this thread since it was started.

Could someone clarify the correct way to specify a filter when the *.dll and it's filters do not match. Which one of these is would be correct:
SetFilterMTMode("rgtools", 1)
SetFilterMTMode("RemoveGrain", 1) <-- This is what I have been using.
SetFilterMTMode("RemoveGrain", MT_NICE_FILTER)

Or do I even need to use SetFilterMTMode for this filter since it was made specifically for the new avisynth+?

(Masktools2.dll is another one, which I use often, that I am not exactly sure how to use multi threaded correctly)

Another question; SetMemoryMax(mb) is not used any more, right? I haven't added it to any scripts since I switched to avisynth+.

btw, I have been using both 32 and 64 bit versions of mt-r1689 (depending on the script) without any major problems. I just wanted to make sure I am writing mt scripts correctly. And I do know you can't call a script function .avsi in a SetFilterMTMode() line.

[TurboPascal7]

Line 2 SetFilterMTMode("", 2) does not do anything because you didn't specify a filter inside "blank".
Actually, it specifies MT mode for all filters which aren't specified explicitly.

Could someone clarify the correct way to specify a filter when the *.dll and it's filters do not match. Which one of these is would be correct:
SetFilterMTMode("rgtools", 1)
SetFilterMTMode("RemoveGrain", 1) <-- This is what I have been using.
SetFilterMTMode("RemoveGrain", MT_NICE_FILTER)

Or do I even need to use SetFilterMTMode for this filter since it was made specifically for the new avisynth+?

You don't have to specify anything with these (http://forum.doom9.org/showpost.php?p=1668101&postcount=92) builds. The correct usage is "RemoveGrain", not "rgtools". This has a problem of applying a wrong MT mode to the old kassandro's removegrain which might break like crazy. This problem has no real workaround now.

Whether you use 1 or MT_NICE_FILTER doesn't matter. MT_NICE_FILTER is just a variable that has the value of 1. You can set it to some other value in your script and break everything horribly.

Another question; SetMemoryMax(mb) is not used any more, right? I haven't added it to any scripts since I switched to avisynth+.
IIRC yes.

[zerowalker]

So smdegrain is compatible with SetFilterMTMode("", 2)?

Meaning my script will be able to run without an issue (no corrupted frames appearing and such)?
Cause i know from before that MT could cause random issues which wasn't something like "If it's working, it works", it could appear randomly.

[TurboPascal7]

So smdegrain is compatible with SetFilterMTMode("", 2)?

Meaning my script will be able to run without an issue (no corrupted frames appearing and such)?
Cause i know from before that MT could cause random issues which wasn't something like "If it's working, it works", it could appear randomly.
No. There is no guarantee that you'll get entirely correct output with any set of filters under any set of MT modes right how.

[zerowalker]

No. There is no guarantee that you'll get entirely correct output with any set of filters under any set of MT modes right how.

Okay that's sadly enough to make me not use it in this circumstance, even though the improvement in speed is quite significant.

Though, i don't mean that in a way to discourage the use or development of it.

Would be quite nice to have a working MT, even if optimization is needed for each plugin, it would be quite worth it for certain ones, QTGMC,smdregrain,MCTD, these scripts could really use any boost given, sadly they are very complex and use a lot of filters.

Must be frustrating work keeping check on those rather than individual plugins.


Anyhow, hope the work continues at any rate, anything is something at anytime;)

[Reel.Deel]

No. There is no guarantee that you'll get entirely correct output with any set of filters under any set of MT modes right how.

Yeah when I was testing Avisynth+ MT I came across a few plugins that would have corrupted output, mainly when using with MT_NICE_FILTER (mode 1). Fortunately most of these filters worked fine with MT_MULTI_INSTANCE (mode 2).

-----

To all who care:

Some of the plugins (I'm sure there's more) with corrupted output with MT_NICE_FILTER:


frfun7 (rev6) - 2013 version works fine
gradfun2db
tcanny
TCannyMod
TDeint
TEdgeMask
TEMmod

All of these plugins work correctly with MT_MULTI_INSTANCE. For additional read the comments here (https://pad.riseup.net/p/avs_plus_mt_modes).


Anyways, I hope ultim is doing good...awaiting his return to continue testing...

[Evil_Burrito]

TurboPascal7, thank you for clarifying.

[zerowalker]

I seem to get crashing when i run this script, at least after a long time (Like 7 hours or something).


Avisource("Z:\Testgraph MagicYUV - FFT3DGPU.avi")

ConvertToYV12(matrix="Rec601", interlaced=false)

Audiodub(WAVSource("R:\Testgraph.wav")).DelayAudio(-0.32).AssumeSampleRate(44100)

SyncAudio(0.9998472741694233)

smdegrain(tr=3,lsb=true,thsad=300,lsb_out=true,search=3,refinemotion=true)

Dither_convey_yuv4xxp16_on_yvxx()


I don't know why, there shouldn't be anything that can cause this.

I am using Avspmod avs2avi so the Audio (SyncAudio) is probably ignored, and even if it's not, that only stretches the audio, just a short function for it.

Other than that, it's only smdegrain, and it should be stable.

So i am wondering that it perhaps has something to do with Avisynth+?

The Crash is a simple: Microsoft Visual C++ Runtime Error