Avisynth core leadership issues

[Koepi]

Hi Richard,

thanks, I feel honoured :)

Well, the versioning is very easy:
If you open up the project's workspace, there is a tab "Resources" (the middle tab). Open it. There open all the "+" signs until you find a string table, double click it. There you have all the version entries, you simply edit them by single/double clicking.

I hope this helps,

regards,
Koepi

[Richard Berg]

Ok, I'm about to re-up the 2.0.1 binary with a correctly-versioned DLL, as well as the registry install/uninstall keys which I also forgot in this revision.

I've removed a lot of extraneous junk from the CVS that was annoying to have locked all the time -- correct me if I'm wrong, Koepi, but the only Visual Studio files you'd need to make a build are *.dsp and *.dsw, right?

Edit -- nevermind, obviously you need the *.rc otherwise my version numbering will be for nothing. *.def and *.plg are still gone until further notice.

[trbarry]

If you don't previously have any resource or version info you can choose Insert/Resource/Version_Info to get a version panel. When you close it choose a file name and folder. Then add it to your project.

- Tom

[Richard Berg]

Alpha channel problems in convert_a.asm -- patched on CVS

[vlad59]

It compile without any problem (except for the link problem that Dividee reported a few post ago).
In fact you need the core sdk and also the directx sdk that was my mistake.

I'll get the latest version on CVS and I'll test again.

In fact you only need the dsp on CVS the dsw is created automatically.

[dividee]

I think avisynth.def is needed, VS complains if it isn't there.

I'm currently working on merge.cpp

A note about filters implementation:
IMHO, it's better to do as much validty checking as possible in the constructor (width, height, pixel format, MMX required...), as it makes GetFrame easier to read and there is no reason to perform these checks for each and every frame.

[vlad59]

avisynth.def is needed by VS6. after adding this file latest CVS compile well.

And I think the automatic copy of the avisynth.dll to c:\winnt\system32 is really tricky as my system is installed on f: (I know I'm strange sometimes) and I spend 5 minutes looking for the dll :D :D

EDIT : Oooops Dividee was faster

[dividee]

I replaced references to c:\winnt by $(SystemRoot) in avisynth.dsp (for vlad59 ;) )

EDIT: re-added avisynth.def

[vlad59]

It would be cool to update the version function (in source.cpp) to reflect the new versionning.

[dividee]

committed some stuff to the CVS:

MergeLuma/MergeChroma now works with arbitrary width (well, multiple of 2 of course, because YUY2). Also fixed a bug relating to the merge into one source file, and a bug relating to calling GetWritePtr before MakeWritable. Might also be a bit faster when wheight<1, not too sure.

Added a bunch of math functions for the scripts:
Sin(f),Cos(f),Pi(the constant),Log(f)(natural log),Exp(f)(exponential),pow(f1,f2)(f1**f2),Sqrt(f)
If you wonder what it might be useful for, try the following script:

clip1=AVISource("background.avi")
clip2=AVISource("overlay.avi")

clip2=clip2.Mask(clip2.BlankClip(color=$FFFFFF))

function CIRCLE(clip clip, clip "LClip", float "angle") {
return clip.Layer(LClip, "Add", 192, round((clip.width-LClip.width)/2 + cos(angle)*100),
round((clip.height-LClip.height)/2 + sin(angle)*100) )
}

Animate(0,1000,"CIRCLE",clip1,clip2,0,clip1,clip2,PI*16)


Finally, I added a script function SetMemoryMax(i), which sets the amount of memory available for avisynth buffers (in Megabytes). Edwin recently made a "fix" in avisynth which limit memory usage to 5MB, which I find much too restrictive. I've left the default in, but added this function so you can customize memory usage. This function can be placed anywhere in your script, except at the end or avisynth will complain the return value is not a clip. If you care, the return value is the number of MB to which the limit was actually set (some sanity check is made on the amount asked for).
For that function, I had to change the IScriptEnvironment interface in avisynth.h (it won't break anything), I hope you won't mind.

[Richard Berg]

That script is very, very cool dividee, and knowing it's just the tip of the iceberg is even cooler.

About to be patched into CVS:
-consolidated CPU-dependent #defines into internal.h
-moved IsClose() into internal.h, it's potentially helpful for a much wider range of functions than just those declared in focus.h
-YUY2 support for Layer...without MMX it's actually slower than RGB mode right now, but optimization forthcoming from poptones
-changed version info in source.cpp

[Wilbert]

Added a bunch of math functions for the scripts:
Sin(f),Cos(f),Pi(the constant),Log(f)(natural log),Exp(f)(exponential),pow(f1,f2)(f1**f2),Sqrt(f)

Very cool! I needed Log(f) a while ago for the script for the delogo filter. I solved this by approximating it by a minimax-polynomial on the interval [1,16].

May I ask you how you approximated those functions? I guess not by their taylor series since the convergence is slow (expect in the exp-case) and around a point.

[Richard Berg]

Right now it's just using the VC++ <math.h> library.

[Wilbert]

MergeLuma/MergeChroma now works with arbitrary width (well, multiple of 2 of course, because YUY2).

Maybe it is a good idea to include a doc with the new AviSynth versions containing the descriptions of the new filters (ok, I've seen a description of the layer/mask filters in one of the threads). This MergeLuma/MergeChroma for example, is that the same as the MergeLuma/MergeChroma filter of Klaus ? See http://cultact-server.novi.dk/kpo/avisynth/merge_as.html.

edit: another question, is the dissolve filter fixed again (in the versions v2.0.0 and v2.0.1)?

[Richard Berg]

I've registered avisynth.org. Website development details have their own thread (http://forum.doom9.org/showthread.php?s=&threadid=28569), just FYI. If anyone wants an email alias (forwarding only) let me know.


Maybe it is a good idea to include a doc with the new AviSynth versions containing the descriptions of the new filters (ok, I've seen a description of the layer/mask filters in one of the threads). This MergeLuma/MergeChroma for example, is that the same as the MergeLuma/MergeChroma filter of Klaus ?

Minus the mods described here, yes. I'm definitely a big fan of good documentation if you haven't noticed...are you volunteering? :)

[Wilbert]

Minus the mods described here, yes. I'm definitely a big fan of good documentation if you haven't noticed...are you volunteering?

Why are people always asking me this ? :) Sure, I want to help writing good documentation. Just tell me what/how to do ...

[Richard Berg]

Maybe you're just that good? ;)

Patched on CVS: crop() no longer overwrites buffer on invalid input

[dividee]

Added a Loop filter, which has the following syntax:

clip.Loop(times,start,end)

Examples:

Loop() # make the clip loop (almost) endlessly
Loop(10) # make the clip loop ten times
Loop(10,20,29) # repeat frames 20 to 29 ten times before going on
# actual clip duration increased by 90 frames
Loop(0,20,29) # delete frames 20 to 29
# actual clip duration decreased by 10 frames

No audio support

[poptones]

Awesome!

[dividee]

I was tired of seeing stuff like:
clip=clip+clip+clip+clip+clip+clip+clip+clip
clip=clip+clip+clip+clip+clip+clip+clip+clip


I fixed Dissolve and ShowFiveVersions.

Is only the admin able to flag bugs as fixed on sourceforge? Didn't find a way to do that.

[poptones]

Just one thing: since these are all integers, shouldn't "number of times" be the LAST variable? As it is if I want to loop unlimited times frames 10-20, how would I do it? I cannot use "0" to indicate infinite, as that's already taken.

loop(10,20) loop 10-20 infinite times

But as it is

loop(10,20) would mean "play frame 20 ten times" and

loop(0,10,20) would play nothing of those frames. And the only way to make it "infinite" would be to do something inelegant like

loop(999999999,10,20)

No?

[dividee]

you can use named arguments:

loop(start=10,end=20) (or just loop(start=10) if 20 is the last frame)

negative values for "times" are also considered infinity:

loop(-1,10,20)

BTW, infinity is 10^7 frames :)

[EDIT:] no, loop(10,20) would mean loop frames 20 to the end of clip 10 times

[poptones]

Cool beans.

BTW, "tweaker" could only be made better by the addition of gamma setting. I never really meant to share HSIAdjust (and didn't even realuze I had until after the fact) because, well, it sucks. It was a quick kludge at a time I was just getting my feet wet.

But there are few filters that allow adjust gamma. Any chance this could be (fairly easily) rolled into tweaker? I don't even have an see machine, and at first glance I'm just lost by the math in that thing.

[Richard Berg]

I've committed to CVS the preliminary MMX optimizations for YUY2-mode Layer and Greyscale. I'm going to up what I have of FastLib, just because, but after tonight I'll be taking a short break from the project until I take care of some things that were owed, um, a long time ago. Should be just 2-3 days, and I'll still be checking email & stuff so if anyone needs something messed with on SourceForge that's no problem, but figured a FYI was in order considering how intense I've been the last 10 days or so by comparison.

[dvd2svcd]

I'm daft. I get a lot of these errors when trying to build it:

FastReadStream.obj : error LNK2005: "public: virtual void __thiscall P1Lib::fMemcpy(void *,void const *,unsigned long)" (?fMemcpy@P1Lib@@UAEXPAXPBXK@Z) already defined in AVIReadHandler.obj

I tried the CVS 4 days and had no troubles building it. But as I said I'm daft. (oh, and I had to add FastLib to Addtional Include Directories to compile it)

Edit:
However if I remove #include "fastlib.h" it builds without problems.

[Richard Berg]

Oops, did I commit the internal.h with #fastlib referenced? That shouldn't have happened...will fix asap...

[Guest]

>It includes the latest tweaks to the Poptones' and my filters, as
>well as integration of a few well-known GPL'd plugins: Decomb, Tweak
>(now part of levels.h), and Merge...more to come when I come back
>from work tonight.

I'd rather not see responsibility for development of my plugins moving to this SourceForge project. You should discuss this with people before you do stuff like this. We'll get diverging versions and things will get all screwed up. You know, like Avisynth.

Please remove my plugin code from this project. Thank you. If you refuse, future work I release will be executable only. Do you want that?

[Richard Berg]

Welcome back!

If you refuse, future work I release will be executable only. Do you want that?
Of course not. It's great to see you here again, but until your return your codebase was essentially fixed so versioning wasn't an issue...if you plan to continue updating them in plugin form then obviously that's no longer the case, but I'm confident there's enough smart people here to come up with a solution.

Please remove my plugin code from this project. Thank you.
I happen to like it, but I can see how merging in lots of plugins looks like a solution in search of a problem. If you don't, I'll be happy to remove yours -- but only if everyone else (or perhaps a majority) agrees. After all, my total contribution to (read: ownership of) the so-called "Avisynth2" is pretty small. In particular, I think Dividee has patched bits of Decomb, so I wouldn't want to throw away his contributions before he responds.

You should discuss this with people before you do stuff like this.
The code was/is GPL...you were attending to important personal stuff...we'll have to agree to disagree.

[Guest]

>I think Dividee has patched bits of Decomb, so I wouldn't want to
>throw away his contributions before he responds.

Dividee and I have worked together well in the past. We do not need
you to mediate between us. He knows I am receptive to any
enhancements or corrections that he might care to send to me.
Indeed, I am grateful to him for his past contributions.

>The code was/is GPL...you were attending to important personal
>stuff...

My email has always been active and I have been responding to my email. This should have been discussed. In fact, I have some new features ready for Decomb and now we have this silly divergence.

Pending further discussions, I want to keep my work as plugins. Again,
I ask you to remove it. Future disclosure of my source code as well as my continued participation here depends on your complying with this reasonable request. Thank you.

[trbarry]

I don't feel I deserve a vote on this since I have not contributed to Avi2synth2 yet (have I? ;) ) but I strongly urge everybody to work this out in a gentlemanly fashion.

- Tom

[sh0dan]

Could it be a solution, that tweak and decomb is considered read-only (and perhaps even made so for everyone, except dividee)?

So in essence, there will be NO changes whatsoever to the filters, and only updated if you do so?

Having decomb and tweak as an internal part of avisynth is very helpful for users, making usage more easy for them - but I see your point, and I'm sure the filters will be removed, if you insist in not having them as a part of AVS2.

RB, dividee and myself have already put a lot of work into AVS2 project, and it seems like the only way of improving and maturing avisynth in an open environment (no videotools.net discusssions here).



Regards, Klaus Post.

[Richard Berg]

I'm optimistic we will, Tom, and very likely in short order.

Donald - the files are gone from my HD, awaiting a few more voices before I commit to CVS. Nothing so dramatic as a vote per se, much less "mediation." (We're all on the same side, I hope; scroll back and you'll see your name nominated more than once when we were looking for leadership.) Just progressing carefully, given that deleting stuff without asking everyone involved has even more potential to offend than the additions that started this discussion.

[poptones]

FWIW, tweak is a much, much better piece of code than HSIAdjust, but they do essentially the same thing - and I have zero problems with improving that ugly bit of code I unwittingly contributed during my early learning experiences.

That resolves the "tweak" issue, I think.

[dividee]

Glad to see you back Donald !

Stupidly, I didn't think about the fact that you might still read you email. Else I (we) would have emailed you, for sure.
I wasn't the first in favour of integrating many plugins, but I admit I felt to the ease of using a public CVS for development and not having to invoke LoadPlugin for usage.

Richard, I didn't touch Decomb. AFAIK, Tweak & Decomb weren't changed since Donald left. This shouldn't be a problem for users, they'll just need to add back the LoadPlugin line. Go ahead and delete them, please.

[Richard Berg]

Ah, yes -- upon closer inspection it was sh0dan who made the edits I was thinking of:
Small optimizations to:
- All decomb filters
- Layer.
All 64bit ints are now 8 byte aligned. Inner loop jumps are 16 byte aligned. (Faster on K7)
You can view the diffs on the CVS (telecide (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/telecide.cpp.diff?r1=1.1&r2=1.2&sortby=date) decimate (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/Decimate.cpp.diff?r1=1.1&r2=1.2&sortby=date)), Donald -- nothing terribly complex is done to the functionality, clearly, though the split into CPP/H files & internal documentation isn't very fun.

I've committed a new avisynth.cpp that does not include the Decomb filters; that should prevent version snafus among users by forcing them to download the latest plugin from your site. With your blessing, it's almost time for v2.10...

[sh0dan]

There are only a few 8-byte alignments in decomb - the optimizations are only minor (1 cycle hit per misaligned integer access).
All jump alignments were in layer.

[poptones]

I put the alignments into layer on the chance they might improve things. I couldn't tell any difference on my machine, but since I couldn't tell any difference I figured it ok to leave'em in. I'm glad it actually pays off on some machines.

I popped into this thread because I was going to ask about the image filter. With the unexpected activity I forgot. Anyway, I was wondering if anyone is working on a "legal" image import filter? I found a nice package the other week and was working on integrating parts of it into avisynth so we can import (and export - more on that later) still images in BMP, JPG, TIFF format. But I'd hate to duplicate someone elses efforts when there are so many other things that also need to be done.

Is anyone else working on this?

Also, I got a bug report that layer was broken. I just hit the AVS last night and compiled the image and it seems to work just fine on this end. Can someone please confirm whether layer is broken in the most recent source image?

[Richard Berg]

I think so, just be sure you have one no more than 4 hours old (v1.11 in the CVS numbering).


Revision 1.11 (4 hours, 17 minutes ago) by richardberg
Fixed EMMS bug in ColorKeyMask, fixed YUY2 detection issues, added friendly error message for Layer ops

Revision 1.10 (3 days, 16 hours ago) by dividee
new filter: ColorKeyMask + bugfix in Layer


The only image filter I know of is no stranger to you (http://forum.doom9.org/showthread.php?s=&threadid=26855)...a GPL'd, integrated alternative would be very nice.

[Guest]

@trbarry

Aren't we all gentlemen and ladies here? I certainly don't want to create any acrimony. But I do feel firmly about keeping Decomb (and my other work) as plugins. Here is why:

1. If the functionality moves into Avisynth, the internal functions override my plugins and I can no longer update them. How would you feel if I killed off all your plugins without even mentioning it to you?

2. I don't want to develop in the SourceForge environment. I am very comfortable with my own environment. I am not even set up to build Avisynth and have no desire to do so at this time.

3. I do not want to tie my work to specific versions of Avisynth.

4. I do not want to have diverging versions that I have to maintain in multiple.

5. There is a good reason that Ben added plugin support, and that Avery steadfastly refused to absorb other's filter natively into VirtualDub. Can you imagine the nightmare that Avisynth will become if all the filters are absorbed? And who will be responsible for testing it all and coordinating with authors?

I think it is a really bad precedent. Surely all the problems are not overweighed by the fact that you can avoid a LoadPlugin line in your script.

@sh0dan

Not really a solution because I simply want to work in my own environment. Is it a crime?

@poptones

As Tweak is mature and unlikely to change I would not object to it being absorbed into Avisynth (notwithstanding the above). But why set the precedent?

@Richard

Thank you. Yes, that will be fine to remove Decomb for the next version. I noted your kind words about me posted earlier and greatly appreciate them. I can see you are a great resource here and I will look forward to getting to know you better and to work together with you. I apologize if I came off badly in stating my views. Onward and upward!

@all

The next release of Decomb will solve issues arising from the decoupling of Telecide and Decimate, e.g., incorrect decimation of some animes, such as Princess Mononoke. After that, I am open to suggestions for new filter work. I see several excellent new filter writers here and that is great because it means we have a stimulating environment and a broader source of ideas. Competition is good! Let's join battle. :)

[Richard Berg]

I agree that integrating plugins opens up a can of worms in cases like yours. It's a nice touch for both user & developer -- when the people maintaining the filter are already active on SourceForge. OTOH, your #5 is precisely why I haven't messed with the latest from MarcFD, Tom, and others even though they would make excellent additions.

[dividee]

I think the integration of Decomb was an error for yet another reason (in addition to the aforementionned).

First a disclaimer: this is late night thinking (5 AM) :)

I like to think about avisynth as a language used to specify "video processing expressions". An expression (=filtergraph) that consists of filters (operators) and clips (operands) (with the special case of source filters which are not operators). In this view, general-purpose filters are much more important than special-purpose filters. I was delighted with filters like GeneralConvolution and Layer, which, I think, really increase the "expressive power" of avisynth. The operation of these filters is well defined and there is no discussion as to what the output should be. As such these filters are highly valuable additions to the avisynth core filterset.
Now, let's take a look at operations such as IVTC, deinterlacing and denoising. There are plenty of methods to accomplish these tasks, and not one can be told to be superior to others in all cases. But I think you'll agree that including a gazillion of such filters in avisynth is not a good idea. These filters are much more susceptible to change over time, and their interface can change too, so it will break previous script. This is much less dramatic if they are external plugins, as a script could more easily be tied to a specific plugin version than to a specific version of avisynth. In fact, avisynth already includes such filters, but quite simple versions of them. Let's keep it that way.

I'm not saying that this should be the only criteria for inclusion in avisynth, but.. well, does any of this makes sense to someone or should I get more sleep ? :p

[Guest]

@dividee

What you say makes a lot of sense to me. You should do more late night thinking.

@Richard

I thought of a good enhancement for Avisynth that will get you what you were after without the nightmare. You know probably that VirtualDub has a plugins directory and that it automatically loads filters found there. Why couldn't Avisynth have this feature as well? Then the user has complete control over what gets plugged in and she avoids having to code the LoadPlugin lines in all her scripts. Some kind soul capable of compiling Avisynth might be convinced to consider this. It wouldn't be hard and would be a very nice addition. No?

[Guest]

Of course I know Klaus through email and the filter website. Now I have connected him to "sh0dan"!

>RB, dividee and myself have already put a lot of work into AVS2
>project, and it seems like the only way of improving and maturing
>avisynth in an open environment (no videotools.net discussions
>here).

100% Absolutely agreed. :)

The three of you have placed us all in your debt for this great work you are doing. Be assured that we appreciate it!

[trbarry]

I am glad to see that everyone seems to be more or less in agreement on the shared filter issue.

In my own case I already have GreedyHMA and TomsMoComp in the DScaler SourceForge project since those filters share code with the DScaler versions of same.

But I've had somewhat mixed feelings about the issue. It is sometimes inconvenient to syncronize releases when I want to put something new out and the other larger project is on a longer development schedule. And there is sort of a greater implied requirement for system & regression testing when you think other folks are relying on certain internal aspects of your code.

I'm still considering adding SimpleResize, Unfilter, STMedianFilter, and other new stuff to Avisynth2 but confess I can't quite make up my mind on the issue. But I'm pretty sure it should be left up to the original author as long as he hasn't orphaned the code.

- Tom

[stickboy]

As a user, I'd also prefer that extensions be made as plug-ins when possible. Especially with the way Avisynth is forking, I don't want to have to keep track of which Avisynth version incorporates what version of which plug-in.
Originally posted by neuron2
1. If the functionality moves into Avisynth, the internal functions override my plugins and I can no longer update them.Is this true? If so, that seems quite troubling. Can Avisynth be modified so that the (most recently loaded) plugin takes precedent when there's a namespace collision? (Possibly a set of keywords would need to be reserved to prevent plug-ins from overriding some core functions.)

[WarpEnterprises]

I completely support the "Late Night Thinking"
Only "well-defined" functions should be in core-avisynth.
Btw, there are two in mpeg2dec which I think are such (BlendFields, SelectRangeEvery) to be added in core.

I'm really glad you all settled the issue (I was quite shocked on neuron2's rough 1st statement...).

Has anyone spent some thoughts on when and how to supersede avisynth 1x n?

[poptones]

I agree with much of this as well. Which now begs the unique question: what ELSE should be removed from the core and added via plugin? The "VCR filters" Ben originally included, for example: how many people have ever used "peculiarblend?" Or "fixbrokenchromaupsampling?"

Frankly, I think the dozen different ways of doing things are going to bog down the code as well. Having ten different resizers doesn't buy flexibility nearly so much as it just makes things more confusing.

[sh0dan]

@pop-tones: I agree - some filters are not used much, but since they aren't broken, I guess leaving them there doesn't hurt much. I added them into an "exotic" section in the doc section along with showfive, stack, reverse and loop.

As for your point on resizers, I think that we'll have to take these discussions as they turn up - I can't see any problem as it is now, and speaking of resizers, I very much hope we'll someday get simpleresize implemented, since it is fast, has good quality and is used by many people.

Until Avisynth gets a good interface, it'll be a specialist's tool, and not used by the very wide public (as vdub). In such a world I honestly see no problems in having different resizers.

I agree we need to have a long discussion on what to include, and what not to include! If there is a filter that offers significant new features, is stable, and used regularly by people here, I'm very pro-including it. Many great features has been lost in plugins, because people never fould them - and it's just plain easier for everybody to use them, if they are included.


BTW, to avoid a misunderstanding - has someone actually tested, if Avisynth prioritizes internal plugins over external? I'm pretty sure it doesn't, and if it does it should be changed! (There is a reason why people import plugins!)

[Richard Berg]

The three of you have placed us all in your debt for this great work you are doing.
Don't forget poppy, Layer() is like the coolest thing ever...

Can Avisynth be modified so that the (most recently loaded) plugin takes precedent when there's a namespace collision? (Possibly a set of keywords would need to be reserved to prevent plug-ins from overriding some core functions.)
When Donald first brought up the issue I realized I hadn't considered this at all. Personally, I don't even see the need for reserved words at all -- the user should have it easy (see below), but should also have ultimate control.

I thought of a good enhancement for Avisynth that will get you what you were after without the nightmare. You know probably that VirtualDub has a plugins directory and that it automatically loads filters found there. Why couldn't Avisynth have this feature as well? Then the user has complete control over what gets plugged in and she avoids having to code the LoadPlugin lines in all her scripts. Some kind soul capable of compiling Avisynth might be convinced to consider this. It wouldn't be hard and would be a very nice addition. No?
Frankly, I dunno why nobody (except Avery, that brilliant bastard) thought of this before. The concept has my total support.

Main stumbling block, methinks: at present, Avisynth doesn't require anything resembling an install directory; all it does is stick a DLL in %WINDIR%\system32. However, I see the project evolving to also include things like sample scripts and/or helper functions designed solely for Include(). Like dividee said the "expressive power" of the language is largely present already; future improvements are likely to be built on the language itself (witness the recent PAL<->NTSC thread) as C++. In short, it's about time we had a proper installer :) Luckily, that's something I have lots of practice with...

I definitely get the gist behind "late night thinking." I had no problem telling Warp on the SF feature request forum that the two mpeg2dec functions would be included in a future release, but got cold feet WRT SimpleResize and others. By the same token, I'm thinking it may be time to give the opposite treatment to stuff like "fixbrokenchromaupsampling."

Closing thoughts: now that all the filters aren't squeezed into 3 giant files, none of the above considerations are a "big deal." It's painless to swap filters in *OR* out, and keeping it that way was/is the only real priority behind the v2.00 reorganization. On the plugin end of things: between the newly Wiki-ized website and forthcoming auto-loader, there's no excuse not to have a nice comprehensive listing & documentation of everything under the sun, which was the whole point anyway.

[dividee]

@sh0dan
Indeed internal filters can't get overrided. IIRC, trying to do so gives an error message. That might be changed, but it's not that important if we choose carefully which plugins are part of avisynth, as then the only use would be to fix bugs or provide a faster implementation, but in these cases it would be better to update the plugin in avisynth.

@all
I second the proposal for a plugin directory. Moreover, not only plugins could be there, but also AVS files that are automatically imported. We could even build some kind of standard library distributed with avisynth, that would contains more exotic functions which are not eligible to be included in avisynth. I don't know if this is a problem to load 20 plugins even if they aren't used, but it should be possible to implement it in a way such as only plugins containing functions that are used in the script are loaded. Might be harder to do for AVS import, but possible nonetheless.