Avisynth 2.0/2.5 plugin chaos (or: why can't 2.5 load 2.0 plugins?)

[Mr.Shine]

Here we go, we have Avisynth 1.x/2.0, and Avisynth 2.5, which can't load plugins compiled for pre-2.5.

Then we have LoadPluginEx from the warpsharp package, which can apparently load 2.0 plugins in 2.5 and vice versa (can it? I only briefly tested the latter).

Then we have loads of people trying to get Avisynth 2.0 and 2.5 to work simultaneously (and even writing switcher-programs!!), because certain plugins they need to use aren't yet available compiled for 2.5 (or no source is available at all), but they still don't want to miss the new features from the new Avisynth version completely - with these people, Avisynth 2.5 is losing a lot of beta testers, since they will switch back to 2.0 whenever they don't really need YV12 processing.

Then we have people (like me) who would love to use Avisynth 2.5, but don't desperately need YV12 processing and thus are still sticking with 2.0 because of the sheer amount of plugins noone felt like compiling for that version yet (or where no source is available at all) - with them, Avisynth 2.5 is also losing lots of beta testers.

Not to speak of the chaos and disadvantages that causes to people who just want to USE the program, without having to worry about plugin versions and incompatibilities (which are artificially created in the first place).

Now let me ask you Avisynth developers for at least ONE sensible reason why Avisynth 2.5, although e.g. being able to load plugins for third-party programs just fine (vdub, vfapi), CANNOT load ITS OWN plugins just because they were compiled for a previous version?
Why can't there be a "LoadOldPlugin" or "LoadLegacyPlugin" function, or even the LoadPlugin function falling back to 1.x/2.0 plugin handling when it doesn't find the ..Init2 export?

Of course, LoadPluginEx is available, probably it even works just fine both ways, who knows, but do we really need, or want, a PLUGIN to be able load PLUGINS? Do we need, or want, that unnecessary overhead?

It would add a lot to the power of Avisynth 2.5 if it could fall back to the huge plugin base there is for previous versions, just like it can use VFAPI and Vdub plugins. In fact, it would completely supercede Avisynth 2.0 then.

Just my 2 Euro-Cents.

P.S.: Thanks to WarpEnterprises for his Avisynth plugin list (http://www.avisynth.org/~warpenterprises/) which, when I saw the huge list of 1.x/2.0-only filters before my eyes, finally motivated me to post my thoughts :-)

[Kurosu]

AVS 2.5 and 2.0x plugins can't be fully compatible because of the API changes. The structures aren't exactly the same, so when pointing at some part of memory, the data there isn't the same for the 2 versions. To be able to run a 2.0x plugin without recompiling, you need a wrapper, able to get the data from avs 2.0x structures to put in 2.5 structures.

That's what LoadPluginEx does. But it contains some C++ (pogramming stuff) that I, for instance, don't understand (well, it would give me nightmares first). The fact is that such problem seems pretty strange from the outside, but is hard to tackle.

This leads me to another point: I had a discussion with a friend that found strange there was no graphic script builder (a la graphedit) or the like, more generally that there were design flaws. The real fact is that such problems, despite their importance, needs an amount of time bigger than available. AFAIK, there are only 3 Core developpers:
- Sh0dan
- Bidoche
- Richard Berg
They are already pretty busy, and there are already important things on their todo list (directshow stuff, avs3.0 planning, compatibility).

AVS2.5 filters can harly be used in 2.0x, because many restrictions can't be known at first (like only working in YV12, which isn't available in 2.0x). Add to this the same need of a wrapper.

[sh0dan]

@Mr.Shine: No offence, but if you place all plugins in the respective plugin directory, switching between both versions are not that much of an issue - only a matter of replacing avisynth.dll, or reinstalling the avisynth version you want to use.

[Richard Berg]

Nevertheless -- it's worth investigating whether LoadPluginEx can be added to the core.

[sh0dan]

It would be great, if you had the time for this one!

[N_F]

Could anyone tell me where to find a warpsharp package containing LoadPluginEx? The last version I've been able to find is about a half a year old and doens't include anything named LoadPluginEx.

[Wilbert]

Last plugin and last version in Q3.4.

[N_F]

Thanks (and sorry...).

[Richard Berg]

FWIW, I had a look at the LoadPluginEx code. I think I understood much of it, but would have trouble integrating it into existing code. Anyone else have any opinions on the matter? Also, from a user perspective, how well does it work?

[Wilbert]

Also, from a user perspective, how well does it work?
I didn't test it thoroughly. But I tried filters like NoMoSmooth, Peach and Dust, and they all worked well.

[N_F]

I only tried it briefly with dust and it seemed to work well. Something that perhaps should be looked into is the speed of it: Avisynth 2.0x + filters for Avisynth 2.0x vs. Avisynth 2.5x + LoadPluginEx + filters for Avisynth 2.0x.

I didn't play with it long enough to see wheter speed took a significant hit or not (perhaps you can judge just by looking at the code anyway).

[CruNcher]

@ Wilbert
i looked in the Avisynth faq on the site and in the newest release and all both are linking to this thread http://forum.doom9.org/showthread.php?s=&threadid=34076 but i cant find this Loadpluginex.dll mentioned in the text nor i can find it in the attachments am i dumb now ? ;)

[Wilbert]

Q3.4:
(...) Last version can be found here (http://www.geocities.co.jp/SiliconValley-PaloAlto/2382/).
.......................................^^^^

I will change it with the next updates :)

[CruNcher]

thx puh and i thought i begin to get blind :p

update: looks like loadpluginex.dll doesn't work anymore with the latest Cvs avisynth 2.51

[Boulder]

Works for me, tested on the binary from SourceForge.

[DDogg]

boulder, did you try it with the latest from Sh0dan's site (in his sig)?

[Boulder]

Originally posted by DDogg
boulder, did you try it with the latest from Sh0dan's site (in his sig)?

Oops, missed that:o I thought that the released beta was still the latest one..sorry for any caused confusion.

[DDogg]

CruNcher, this worked ok for me with the march 19 csv version from Sh0dan's sig.

LoadPlugin("LoadPluginEx.dll") # Warpsharp and this DLL must NOT reside in Plugins dir see note **
LoadPlugin("D:\Temp\DustV5.dll")# source interlaced DV
AviSource("V:\Video_Cap\Clip 001-8.avi")
AssumeFieldBased() # Still proper to use? Confused on that
FixBrokenChromaUpsampling()# People have said this is needed with Canopus DV codec
ConvertToYUY2(interlaced=true)
PixieDust (5)


** http://forum.doom9.org/showthread.php?s=&threadid=49492

[CruNcher]

@DDogg
ah i thought it would be loaded autmaticly left in the plugin dir was not aware that this produces errors i'll try again with the 25 march release of avisynth thx :)

[sh0dan]

You should get the same result with:

LoadPlugin("LoadPluginEx.dll") # Warpsharp and this DLL must NOT reside in Plugins dir see note **
LoadPlugin("D:\Temp\DustV5.dll")# source interlaced DV
AviSource("V:\Video_Cap\Clip 001-8.avi")
FixBrokenChromaUpsampling()# People have said this is needed with Canopus DV codec
PixieDust (5)

AssumeFieldBased() - doesn't do anything in your script.
ConvertToYUY2 - Your source is already YUY2().

Does PixieDust treat interlaced video properly? I seem to remember it is a spatial filter, so you should probably use:

SeparateFields().PixieDust(5).Weave()

[Wilbert]

Does PixieDust treat interlaced video properly? I seem to remember it is a spatial filter, so you should probably use:

SeparateFields().PixieDust(5).Weave()
PixieDust is a spatio temporal filter, so I guess you can't use that at all? Maybe I'm wrong but you only use spatial filters on an interlaced source. So try

SeparateFields.SpaceDust(5).Weave

[IanB]

SeparateFields().PixieDust(5).Weave()

PixieDust is a spatio temporal filter...
Also try :-SeparateFields()
E=SelectEven().PixieDust(5)
O=SelectOdd().PixieDust(5)
Interleave(E,O).Weave()
IanB

[DDogg]

Thanks all, I'll give all the variations suggested a try. Interlaced filtering always befuddles me. :confused:

[crusty]

@Sh0dan

I wouldn't suggest using Pixiedust on separate fields.
I tried it and it didn't it at all, it kinda flipped and produced a completely messed up clip.

I don't think Pixiedust can be placed between SeparateFields and Weave.

[Didée]

In the readme of dustv5, there is written that the filter can only be used in one instance in the filter chain.

[Wilbert]

Where in the readme?

[Didée]

Ooops - sorry.

It was not in the readme shipping with the package - it was in the BIG readme (http://forum.doom9.org/showthread.php?s=&threadid=42749). ;)

[Wilbert]

Ok, I've seen it. It's for the reason I said above.

[crusty]

I've worked about a month now with Pixiedust on some very noisy material, and while it's cleaning out a lot of noise it does produce too much blocking artifacts to be of good use, at least at the resolution where I'm working at. (544x244 and 576x240)
Maybe the artifacts are less visible at higher resolutions but in the end I got way better results with the combined use of PeachSmoother and FluxSmooth.

[TNM]

Originally posted by crusty
I've worked about a month now with Pixiedust on some very noisy material, and while it's cleaning out a lot of noise it does produce too much blocking artifacts to be of good use, at least at the resolution where I'm working at. (544x244 and 576x240)
Maybe the artifacts are less visible at higher resolutions but in the end I got way better results with the combined use of PeachSmoother and FluxSmooth.
I was also working with PixieDust for a while and also quite irritated with the blocks it created...:( Can u pls post some good settings for the combination of PeachSmoother and FluxSmooth? Thanks :)

[neuron2]

This thread has lost its focus. Please start a new thread in the usage forum with an appropriate title. Thread closed.