Avisynth+

[ajp_anton]

So from the planar/packed discussion, it seems that:
Packed is only needed for output. Otherwise it's easier (shared code with planar YUV) and faster (non-ancient CPUs only?) to process. Therefore IMO planar should be the default RGB format with ConvertToRGB24 etc, and Avisynth should only convert to packed before outputting (can it detect if whatever's at the other end wants packed or if it supports planar?). There should also be a "packed"-named bool argument when converting to any RGB format, in case an old filter requires it. What do you think?

[StainlessS]

There should also be a "packed"-named bool argument when converting to any RGB format, in case an old filter requires it.

With default true, unless intent is to break nearly everything ever written.

[tuanden0]

@Groucho2004: :thanks:

That was great, no crashed with MT mode 3 and I can use the fft3dgpu setting for fft3dfilter. :D

[TheFluff]

Regarding 2.: I don't say DIB compatibility is a "good" idea. I only say some people still use "legacy" software which doesn't know it better than that. And if packed RGB would be removed from AviSynth(+), then you could probably not use AviSynth(+) anymore in conjunction with such tools or plugins.

The questions were:

a) Why are there both worlds? – Legacy, compatibility, and different advantages for different kinds of use.

b) Should AviSynth(+) get rid of one? – Only if compatibility with legacy software doesn't matter.

I think you're kinda missing the point here. Supporting everything under the sun plus the kitchen sink is of course "good" for the end user, but it's not free - it adds complexity, both to the user and to the programmer, and it adds maintenance costs (work on an enthusiast project may be free as in beer, but it has a non-monetary price nevertheless). If one standard way of doing things is agreed upon, the process of interacting with the filtering framework is streamlined and eased for everyone - people using it, people writing filters for it and people maintaining the framework itself. That is highly desirable.

Nobody has suggested that input or output of packed RGB should not be supported. Not even VS goes that far, despite a wholehearted desire to throw out everything old. As you say, there are still important legacy systems that you kinda have to deal with that only support packed.

What has been proposed is to only use planar RGB internally, and automatically pack/unpack on input and output. The reasons for this are as follows:

1. Packed 8-bit RGB is an oddity in 2017. Literally everything else is planar - higher bitdepth RGB, YUV, YCgCo, etc. If you switch to planar as a standard, there is a not insignificant number of filters that can be adapted to use the same code path for all colorspaces, which is pretty huge for maintenance.

2. It's essentially free. Packing or unpacking is barely more expensive than copying the frame, and as Myrsloik points out you almost always have to do that at each end of your filter chain anyway.

3. It has performance benefits, especially for filters that want to treat some components differently or pass them through unchanged. Some filters could in theory benefit from packed, but since those benefits are 8-bit RGB only that's almost completely irrelevant, and it is likewise theoretically possible to rewrite the algorithm to benefit from planar instead.


Now, to fully reap these benefits you must standardize on planar, or you're still left with the whole legacy codepath maintenance garbage. Hence, if you want to support legacy RGB filters you should pack/unpack automatically on input/output from those. That should hopefully give people an incentive to update their filters to avoid the (admittedly rather minor) performance hit.

[LigH]

OK, understood ... "internally", for the core filters, this would surely be a good idea, assuming that the benefits are as obvious as you explain them (which I would probably agree with). You may just need to repack not only for the final output to the calling application, but also for plugins supporting packed RGB and addressing frame content directly (if this is included in your statement "automatically pack/unpack on input and output", you already considered that). And new plugins working in RGB space will surely be written to support it in planar organization as well when compatibility specifically to AviSynth+ is desired.

[jpsdr]

Based on the CS_xxx naming, maybe these were originally intented to appear in the pixel_type. But as VideoInfo:: pixel_type is directly used for checking/setting the video format, using these chroma placement bits in pixel_type would break plugins and avisynth itself.


// Chroma placement bits 20 -> 23 ::FIXME:: Really want a Class to support this
enum {
CS_UNKNOWN_CHROMA_PLACEMENT = 0 << 20,
CS_MPEG1_CHROMA_PLACEMENT = 1 << 20,
CS_MPEG2_CHROMA_PLACEMENT = 2 << 20,
CS_YUY2_CHROMA_PLACEMENT = 3 << 20,
CS_TOPLEFT_CHROMA_PLACEMENT = 4 << 20
};

I didn't read properly.
Do you mean that these bits are already used for something else, so i can't use them for checking the chroma placement ?

[pinterf]

These chroma placement bits are defined but nowhere used.
At many places VideoInfo.pixel_type is checked and set directly. (like vi.pixel_type == VideoInfo:: CS_YUV420P16, or vi.pixel_type=VideoInfo:: CS_YV12)
If we put chroma placement bits in VideoInfo.pixel_type then all these comparison will fail because they modify the pixel_type constants. The bits could be masked out before comparison like VideoInfo::IsColorSpace does now, but I think for the placement (and any other) metadata we should use the image_type property in order not to break existing plugins.

[jpsdr]

Ok, thanks for the clarification.

[chummy]

Hello, so i have a script with MFlowBlur which works with SET Avisynth MT but cannot make avisynth+ MT work on it.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ffvideosource", 3)
SetFilterMTMode("RGtools", 1)

[StainlessS]

Chummy, Pinterf will want some kind of script he can test, post the whole script including MFlowBlur().

[chummy]

RemoveGrain(2,5)
UUMblur3()
return Last
####
function UUMblur3(clip C, int "percentblur", int "speed")
{
Assert(C.IsYV12, "source must be YV12")

percentblur = Min(Max(0, Default(percentblur, 30)), 80)
speed = Default(speed, 0)

super = MSuper(C)

## slow : medium : fast
B = (speed<0)
\ ? MFlowBlur(C, super,
\ MAnalyse(super, search=3, searchparam=24, truemotion=true, isb=true),
\ MAnalyse(super, search=3, searchparam=24, truemotion=true, isb=false),
\ blur=Float(percentblur))
\ : (speed==0)
\ ? MFlowBlur(C, super,
\ MAnalyse(super, search=4, searchparam=16, truemotion=true, isb=true),
\ MAnalyse(super, search=4, searchparam=16, truemotion=true, isb=false),
\ blur=Float(percentblur))
\ : MFlowBlur(C, super,
\ MAnalyse(super, search=4, searchparam= 2, truemotion=true, isb=true),
\ MAnalyse(super, search=4, searchparam= 2, truemotion=true, isb=false),
\ blur=Float(percentblur))

return (percentblur==0) ? C : B
}

[Groucho2004]

Hello, so i have a script with MFlowBlur which works with SET Avisynth MT but cannot make avisynth+ MT work on it.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ffvideosource", 3)
SetFilterMTMode("RGtools", 1)
Can you elaborate on "cannot make avisynth+ MT work on it"?

[chummy]

With Set MT it's capable to use all threads from my CPU and speed up the processing by almost 3.5x, while without multithreading in Avisynth+ it stuck to slow speed. 1.60fps with avisynth+ single-thread process and 15% CPU usage, while with SET multithreading it achieving almost 6fps and 90% CPU usage. Avisynth+ MT works for some other scripts which i tried but not for this one. I hope that explain what i trying to say.

[Groucho2004]

With Set MT it's capable to use all threads from my CPU and speed up the processing by almost 3.5x, while without multithreading in Avisynth+ it stuck to slow speed. 1.60fps with avisynth+ single-thread process and 15% CPU usage, while with SET multithreading it achieving almost 6fps and 90% CPU usage. Avisynth+ MT works for some other scripts which i tried but not for this one. I hope that explain what i trying to say.
Where did you put the "prefetch" statement?

[chummy]

Where did you put the "prefetch" statement?
At bottom like any other script.

[Groucho2004]

At bottom like any other script.
If you put it at the bottom of the script you posted above it will of course not work, the unnecessary "return last" prevents it from being executed.
Post the entire script.

[chummy]

If you put it at the bottom of the script you posted above it will of course not work, the unnecessary "return last" prevents it from being executed.
Post the entire script.

Thanks for the information, so i put prefetch before return last and multithreading is working fine.

[gaak]

Just started using 64 bit Avisynth+ for my project and it's working out fine. I was wondering if there is a formal way to request a 64 bit version to be made from a 32 bit source? I can't find a 64 bit version of RoboCrop. I asked the author and he is unable to do it because he only has a 32 bit system. I know AutoCrop is available and have been using it, but I find RoboCrop to be more reliable. Thanks.

[wonkey_monkey]

This may be a stupid question but I've just migrated to Avisynth+. I installed the FilterSDK, but where is, or what is the name of, the header file I should be including in my plugin development projects from now on? And is there an avisynth+.lib I should be linking too?

I usually get these things working by trial-and-error...

---

Also, should I have an avisynth+.dll somewhere? It's all installed and working, but I can't find a file called that, and any avisynth.dlls I can find (x86 and x64) are 2.6.0.5.

[JoeyMonco]

You either include avisynth.h or avisynth_c.h (depending on whether you want the C or C++ API) just like normal avisynth. The DLL and lib are still also just called avisynth, not avisynth+, as well. If the DLL were renamed it would no longer be a drop-in replacement for classic Avisynth...

[Groucho2004]

I installed the FilterSDK, but where is, or what is the name of, the header file I should be including in my plugin development projects from now on?Use the AVS+ headers from here (https://github.com/pinterf/AviSynthPlus/tree/MT/avs_core/include).
And is there an avisynth+.lib I should be linking too?If you need it (only when you're writing c-plugins), you have to build it yourself with the AVS+ sources.
Also, should I have an avisynth+.dll somewhere? It's all installed and working, but I can't find a file called that, and any avisynth.dlls I can find (x86 and x64) are 2.6.0.5.It's avisynth.dll, also for AVS+. If you have 2.6.0.5 versions you probably did something wrong, I recommend uninstalling all traces of previous versions and cleaning the registry and plugin directories before installing AVS+.
By the way, there is no 2.6.0.5 64 bit version as far as I know.
Edit: I stand corrected. There is a 2.6.0.5 64 bit version, I forgot about AVS+ r1576.

[wonkey_monkey]

It's avisynth.dll, also for AVS+. If you have 2.6.0.5 versions you probably did something wrong

Here's the properties of the DLL in System32:

http://i.imgur.com/Y3p9gyt.png

It says Avisynth+ 2.6...

If you need it (only when you're writing c-plugins)

I guess I'm doing something wrong, then, since I can't compile without linking to it, and also need to define AVS_LINKAGE_DLLIMPORT... these are unfortunately all the things I've never tried to understand, because I just did them and they made it so I could write filters to monkey around with pixels (which I do understand).

Otherwise I get this:

error LNK2001: unresolved external symbol "__declspec(dllimport) struct AVS_Linkage const * const AVS_linkage" (__imp_?AVS_linkage@@3QBUAVS_Linkage@@B)

[pinterf]

This version could be the old v1576?

[wonkey_monkey]

It's what you get when click the big "Installer" button at www.avs-plus.net.

[qyot27]

Here's the properties of the DLL in System32:

http://i.imgur.com/Y3p9gyt.png

It says Avisynth+ 2.6...
Then you definitely need to upgrade, because that version of AviSynth+ (I'm guessing you just installed 0.1/r1576 from the project page, or possibly one of the really early builds from the MT branch, given the 2014 modified date) has been outdated for a long time; it was released three years ago. On a partially separate tangent, a 'stable' 0.2 release has been right on the cusp of being released for over a year but stuff just keeps sidetracking it, which is why simply using the periodic builds from git is the normal thing here.

The latest build by ultim (I can't remember what the revision number was...r2173?) or the latest one by pinterf (r2380) is the one you should be using.

[wonkey_monkey]

Eh... well I get why things are the way they are, but it's this kind of situation that could easily put someone off ever trying to use Avisynth in the first place. The original 2.6 is outdated, or so advice I've seen hereabouts says, but the most prominent link to install the modernised fork is also out-of-date with no obvious instructions on how to get an up-to-date version, even if it is a beta...

So I got r2380, copied the x86 DLL to SYSWOW64 and the x64 DLL to System32, and copied the plugins+ and plugins64+ folders over their counterparts that were previously installed... and now I get "AVI Import Filter error: (Unknown) (80040154)" from just a "version" script.

Should I just go back to 2.6? My plugins seem to work okay with Avisynth+ anyway.

---

Edit: I finally figured out how to use AvisynthPluginInit3 instead of AvisynthPluginInit2 and now I don't need to link to avisynth.lib any more ¯\_(ツ)_/¯ I shall just stick to r1576 since it was good enough to have an installer at some point in history, and I've not had any problems with it so far.

[LigH]

It's what you get when click the big "Installer" button at www.avs-plus.net.

:rolleyes: It's such a pity that the official website is so outdated. You'll find recent MT versions by scanning this thread backwards carefully. :eek:

[real.finder]

:rolleyes: It's such a pity that the official website is so outdated. You'll find recent MT versions by scanning this thread backwards carefully. :eek:

or here http://avisynth.nl/index.php/AviSynth%2B#Downloads

[Bexley]

Just started using 64 bit Avisynth+ for my project and it's working out fine. I was wondering if there is a formal way to request a 64 bit version to be made from a 32 bit source? I can't find a 64 bit version of RoboCrop. I asked the author and he is unable to do it because he only has a 32 bit system. I know AutoCrop is available and have been using it, but I find RoboCrop to be more reliable. Thanks.

There is a 64-bit version here (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins) but I haven't tried it.

I also have just made the move over to AVS+ because I am finding x64 is able to do things that x32 can't, like TemporalDegrain MT on 1080p source. I'm still trying to work a lot of things out with plugins, and I'm having problems with RemoveDirtMC_SE. I have mvtools, masktools, rgtools, and fluxsmooth from the link above. I also have avsrecursion from Kassandro's RemoveDirt_x64 package. I can't find anything for NLmeansCL in x64, BUT I didn't have them on my x32 system either and it worked. :confused:

When I try to load RemoveDirtMC_SE, I get the following error.Script error: Clense does not have a named argument "cache"
If I edit the function script and remove the cache argument, I get the same error with RestoreMotionBlocks. I know this is an RGTools/RemoveGrain/RemoveDirt error somehow because I've seen it before a long time ago, but I can't remember or figure it out.

Anyone have suggestions?

[Reel.Deel]

@Bexley

RemoveDirtMC_SE uses a lot of older plugins that can probably be replaced by more modern ones. For example, modify the script to use KNLMeansCL instead of NLMeansCL. Regarding the cache parameter, RGTools does not have this parameter so remove all instances in the script. Onto 64-bit RemoveDirt, this version was claimed to be incompatible with the old AviSynth64 so it's a possibility that it also might not work in AviSynth+. See the note that I added at the bottom of the RemoveDirt wiki page:

Note: This version is incompatible with AviSynth, it's only here for reference! For more information on incompatibility read post 5 through 14 here (http://videoprocessing.fr.yuku.com/topic/127).

Edit:
:rolleyes: It's such a pity that the official website is so outdated. You'll find recent MT versions by scanning this thread backwards carefully. :eek:

As real.finder already stated, the AviSynth+ wiki page (http://avisynth.nl/index.php/AviSynth%2B) is the easiest way to keep up with all of the changes. I haven't been as active on the forums as of late but I still try to keep the wiki page up-to-date.

[real.finder]

Regarding the cache parameter, RGTools does not have this parameter so remove all instances in the script.


but it work for me with RGTools! maybe because I have AvsRecursion.dll

[Bexley]

RemoveGrainMC_SE uses a lot of older plugins that can probably be replaced by more modern ones. For example, modify the script to use KNLMeansCL instead of NLMeansCL. Regarding the cache parameter, RGTools does not have this parameter so remove all instances in the script. Onto 64-bit RemoveDirt, this version was claimed to be incompatible with the old AviSynth64 so it's a possibility that it also might not work in AviSynth+. See the note that I added at the bottom of the RemoveDirt wiki page:

Right, that clears up quite a bit. Thanks. That's where I got the package from, but I guess I didn't read far enough down. When I edit the function to remove the "cache" argument, it vomits all over my screen complaining that there is no function named RestoreMotionBlocks. If I'm reading kassandro's posts correctly, without an x64 version of RemoveGrainT, there is really no way to get it working. Right? If that's the case, can you recommend something comparable?

[Reel.Deel]

but it work for me with RGTools! maybe because I have AvsRecursion.dll

That's great! I've yet to try it, if it does indeed work, I'll add it to the x64 plugins list.

Hello, so i have a script with MFlowBlur which works with SET Avisynth MT but cannot make avisynth+ MT work on it.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ffvideosource", 3)
SetFilterMTMode("RGtools", 1)

Just a few observations:

Starting from AviSynth+ r2069 you don't really have to set an MT mode for source filters:
- Avs+ will now automatically recognize source filters. If it sees a source filter which has no MT-mode specified at all, it will automatically use mode 3 instead of the default MT mode. This is great for source filters as in their case it rarely hurts performance and they often need mode 3 anyway, and it will help yet unclassified source filters perform correctly without any user action. One step closer to the "it just works" target.


SetFilterMTMode("RGtools", 1) is incorrect. You have to use the filter name not the plugin name. For example, RgTools has RemoveGrain, Repair, Clense, etc. So to correctly set an MT mode you would write SetFilterMTMode("RemoveGrain", 1) or SetFilterMTMode("RgTools_RemoveGrain", 1). You'll have to do this for each filter included in the plugin.

[Bexley]

but it work for me with RGTools! maybe because I have AvsRecursion.dll

I also have that, but it's from kassandro's package that may or may not be incompatible. Where did you get it?

[real.finder]

That's great! I've yet to try it, if it does indeed work, I'll add it to the x64 plugins list.


in x86, in x64 it's not work, is the rgtools in x64 different or something?

[Reel.Deel]

Right, that clears up quite a bit. Thanks. That's where I got the package from, but I guess I didn't read far enough down. When I edit the function to remove the "cache" argument, it vomits all over my screen complaining that there is no function named RestoreMotionBlocks. If I'm reading kassandro's posts correctly, without an x64 version of RemoveGrainT, there is really no way to get it working. Right? If that's the case, can you recommend something comparable?

real.finder claims the 64-bit RemoveDirt plugins works. If that's true then you might be missing the runtime dependencies.

You don't need RemoveGrainT, the RemoveDirt script uses Clense, ForwardClense, and BackwardClense which is already included in RgTools.

[real.finder]

I also have that, but it's from kassandro's package that may or may not be incompatible. Where did you get it?

there are AvsRecursion_x64.dll by kassandro but it's seems broken or something else is

[Reel.Deel]

in x86, in x64 it's not work, is the rgtools in x64 different or something?

Ok you're confused. We're not talking about RgTools working or not, we're talking about the 64-bit RemoveDirt from here: http://avisynth.nl/index.php/RemoveDirt

See note at the bottom.

[real.finder]

real.finder claims the 64-bit RemoveDirt plugins works. If that's true then you might be missing the runtime dependencies.

You don't need RemoveGrainT, the RemoveDirt script uses Clense, ForwardClense, and BackwardClense which is already included in RgTools.

I didn't, see my post above :D

and RemoveDirtMC_SE need RemoveGrainT for it's prefilter

[real.finder]

Ok you're confused. We're not talking about RgTools working or not, we're talking about the 64-bit RemoveDirt from here: http://avisynth.nl/index.php/RemoveDirt

See note at the bottom.

away form RemoveDirt, I mean the RgTools and cache parameter

[Reel.Deel]

I didn't, see my post above :D

and RemoveGrainMC_SE need RemoveGrainT for it's prefilter

You claimed in post #2881 that RemoveDirt worked, but you were talking about 32-bit while we were discussing 64-bit.

So I guess it does need RemoveGrainT for TemporalRepair, I missed that. There's probably an alternative or a work around though. Anyways it's probably best it we take this discussion elsewhere. Starting to be a bit off topic for this thread.

Your post are sometimes very confusing :D

[real.finder]

You claimed in post #2881 that RemoveDirt worked, but you were talking about 32-bit while we were discussing 64-bit.

I was mean RgTools with cache parameter, anyway, yes, RemoveDirt not work in x64, just did test

[gaak]

There is a 64-bit version here (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins) but I haven't tried it.

@Bexley: Thanks, I'll try it now.

EDIT: @Groucho2004: Just looked at the file date. Wow, looks like you just did it today (well now it's yesterday). Thank you very much. Now that's quick!

EDIT2: @Bexley: Using it now, works great!

[pinterf]

New dev build.
Avisynth Plus r2397-dev (http://www.mediafire.com/file/bazu8v58ab318j6/avsplus-r2397.7z)

20170119 r2397

TemporalSoften: Planar RGB support
Speed: TemporalSoften: much faster average mode (thres=255)
radius=1 +70%, radius=2 +45%,
16bit: generally 7-8x speed (SSE2/4 instead of C)
SeparateColumns: 10-16bit,float,RGB48/64
WeaveColumns: 10-16bit,float,RGB48/64,PlanarRGB(A)
AddAlphaPlane: fix function parameter type list, clip type did not work
Internals: add SubframePlanarA to IScriptEnvirontment2 for frames with alpha plane
SwapUV: YUVA support
ConvertToRGB32/64: copy alpha from YUVA
SeparateRows,SeparateFields: PlanarRGB(A),YUVA support
WeaveRows: PlanarRGB(A), YUVA
Weave (fields,frames): YUVA,PlanarRGB(A)
Crop: Fast crop possible for frames with alpha plane (subframe)
AddBorders missing l/r/top/bottom vs. subsampling check for YUVA
Fix: YUVA->PlanarRGBA and YUVA42x->444 missing alpha plane copy
Speed: YUV444->RGB48/64: fast intermediate PlanarRGB(A) then RGB48/64 (instead of C)
Speed: RGB48/64->YUV4xx target: Planar RGB intermediate (instead of C, 10x faster)


I have one thing left in my list, to make Overlay work for Planar RGB (also as a new intermediate format for old packed RGB formats) and make it work in general without converting to 4:4:4 internal format.

[real.finder]

New dev build.
Avisynth Plus r2397-dev (http://www.mediafire.com/file/bazu8v58ab318j6/avsplus-r2397.7z)


big thanks :)

days ago I try use444=false in y8 then I get error that it's not supported, does that mean that y8 now don't convert to 444? (mean that it will be faster than normal avs in y8)

[pinterf]

Internally the processing still needs exactly three planes. Mask is also faked to 444 even if it is y8 only. I want to remove all these overheads. Integrating rgb to other modes than blend is harder a bit, but it is only a question of working effort.

[gaak]

I just tried to download your latest dev from mediafire. They launch other web pages when this is done. This last attempt launched a page that told me I had a virus and locked the computer. When I shut down and restarted my WiFi settings no longer show and I cannot bring them back. Of course, this is the 1st time my backup has failed. This is going to take a while.

[pinterf]

I have not experienced such behaviour from this site, sorry for that

[kypec]

I just tried to download your latest dev from mediafire. They launch other web pages when this is done.
I guess that uploading binary builds directly on github should be perfectly fine, isn't it? :thanks:

[gaak]

I have not experienced such behaviour from this site, sorry for that

First time for me too. I was able to get it back, I was just surprised/shocked.