Avisynth core leadership issues

[Richard Berg]

It's been my experience that by far the biggest factor in the success of volunteer efforts is leadership. While it might be illustrative, there's no need to spend an opening paragraph telling my life story -- just look around the nonprofit sector, the military...and of course, the OSS world.

Right now Edwin is the project admin at SourceForge, but his focus seems to be elsewhere these days. That's probably for the best considering his modus operandi conflicts with that of (AFAICT) everyone else. Even assuming he's willing to hand over the keys, that doesn't answer the question of who's in charge going forward. Donald would be an easy nomination for me anyway -- he's done an excellent job maintaining the filter archive and has contributed at least as much code as anyone else over the years -- but he hasn't posted since his family emergency thread. (Yet his website is still updated...??) Dividee's posted the most recent diffs, but he's also the only Doom9'er registered as a developer so who knows whether that indicates anything.

Ok, let's say we get a new admin and add a bunch of people to Sourceforge. With Avisynth the thorny issues are still far from over...which is to say, the new leader has his work cut out for him if he's gonna do it right. The layout of the source code means that contributions are either within existing files or in totally separate plugins. A quick pro/con between these options follows below, but what we really need is a better architecture (for the file structure; the code's architecture is great) that with a bit of focus should easily render the "advantages" of plugins moot. The docs are also in major need of repair, with of course consistent updating as progress is made.

Advantages of editing effects.cpp & its ilk:
-coherent versioning
-no possibility of devs getting lazy about releasing source
-users don't have to download a buncha plugins scattered across the web
-users don't need special plugin syntax

Advantages of adding plugins:
-devs don't need to worry about CVS conflicts
-users can "customize" avisynth versions w/o a compiler
-supports authors who won't release under GPL

Well I've said enough for now; the replies to this topic are where the real work will be done. Any other commentary on the overall direction of the Avisynth project is welcome, too.

[trbarry]

Richard -

Is the current Sourceforge even where it is happeniing for Avisynth? I'm not registered as a developer for Avisynth but I went looking the other day and it didn't even look like any files were available there.

But maybe I just missed something.

But I know from DVD2AVI/Save-oe that some projects seem to sit dormant for awhile and then something will touch off a flurry of activity. That project also mostly lacks an active leader.

And I'm more of a helper/follower myself, at least most of the time. I'm willing usually to follow any practical take-charge person who manages to get everybody marching more or less in the same direction. ;)

But I will add one thing. It seems it should be possible to add at least source plug-ins just by checking them into Avisynth Sourceforge. Most wouldn't have to be in Effects.cpp, which could grow ungainly. Some filters could be sub projects but it could still allow synchronized releases for those developers who wanted to put them there. And of course folks would still hopefully be free to keep and maintain their versions instead.

- Tom

[Richard Berg]

Well, part of my motivation here is that I really have no idea "where it's at." Dividee checked in some fixes to SourceForge just 3 days ago, and the Yahoo mailing list (only place I know of where Matthias Born, Ole Hanson, and Avery write about avisynth...though for all I know there's a forum somewhere) is still decently active. Regardless, it's by far the best way to manage things going forward.

Putting new filters in separate files would work easily and isn't a hard fix, but it won't happen just because I say so. Moreover, it's not a cure-all; there's still a lot of patching being done on the existing filters, which are currently stuck in these ridiculously long CPP files. (A lot of times the function headers are mixed in there too!) I'm no refactoring expert, but I haven't seen it discussed at all so I figured it was one of the important issues to bring up if only as an example of the kind of administrative tasks facing us.

I too am definitely a follower for now; if my post gave the impression I was nominating myself, that's about 180 degrees opposite from what I meant :)

[trbarry]

I'm also not a member of that mailing list or forum. Maybe Dividee or the folks there would have some more opinions about all this.

Myself, I sometimes get the urge to do something creative in the short term but have never taken on any lasting longer term responsibility on any of these projects.

But I certainly hope Avisynth continues to evolve.

- Tom

[dividee]

For sure I'd like to see a more active leadership for the avisynth project. I'm not volunteering, I'm a follower myself, surely not a leader. I don't criticize Edwin, but its focus is not on the evolution of this OSS project. It seems he's not willing to do more than fixing small bugs in avisynth core (the fact that, since Ben Rudiak Gould disappeard, we only got new "1.0 beta" versions is symptomatic, I think. Also, why didn't he follow the versionning from the CVS, when he released beta6? this is confusing). At the same time, he is probably the most active at developing new functionnality (such as compressed audio input). But he releases them as closed source plugins, and I don't think it's doing any good to avisynth itself.

I didn't know about the existence of that mailing list (http://groups.yahoo.com/group/avisynth-dev/)! I just browsed the archive a bit. Some interesting posts there, such as n°420 (you must register to access it).

About the plugin vs internal filter issue:
No firm opinion here. If I understood you right, some advantages you mention for internal filters suppose you completely remove the plugin interface. I like the plugin interface :p. This is anectdotic, but about one year ago, I stumbled upon the (still) preliminary avisynth plugin tutorial (http://math.berkeley.edu/~benrg/avisynth-extensions.html) and thought "looks easy enough, let's try it". Before that, no code I wrote ever left my HD (except for some teacher floppy, maybe ;) ). So my (biased) opinion is that writing plugin is still the easiest way for an aspiring developer to get on the boat.

Maybe just rassembling all GPL plugins into the CVS would be a good start (after the refactoring you talk about; I'd love to see effects.cpp and the like broken apart).

[manono]

Hi-

Not to get off topic, but more than once I've read that Ben Rudiak Gould has disappeared, like he's gone into seclusion or become a hermit or something. But that is far from the truth, and what he's working on now will be of great interest to many of the Doom9 regulars. You can find more information about his current project here (http://www.roundelay.net/dvdsynth/prerelease.html).

[Chibi Jasmin]

Originally posted by manono
Hi-

Not to get off topic, but more than once I've read that Ben Rudiak Gould has disappeared, like he's gone into seclusion or become a hermit or something. But that is far from the truth, and what he's working on now will be of great interest to many of the Doom9 regulars. You can find more information about his current project here (http://www.roundelay.net/dvdsynth/prerelease.html).

Quite a nice tool btw. I personally use the unrestrict filter to watch some dvds with (normally) forced subs without the subs :D

[Richard Berg]

Well I got in touch with Edwin; for better or worse he's still interested in coding for Avisynth. No need to speak for him, though -- with any luck he'll post here himself.

Meanwhile, I've started tackling the job of reorganizing the source. It's not easy even when there's a "code freeze" in place; right now there's practically the opposite. I just ask that until this is sorted out, everyone keep diffs of their revisions vs. the "well-known" versions of the respective files, in case we have to merge the hard way.

[Richard Berg]

Ok, I've audited pretty much every line of code in this sucker. Except for one or two core avisynth files that were clear & OO enough as is, I've separated the declaration and implementation of all classes & methods; globally instituted a lot of new readability conventions; split giant files into logical groups of classes; and much more.

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'm not saying this should be the new official 1.0 beta 9 just yet -- it would definitely wreak havoc if merged with the CVS repository, for one! -- but it's a big step in the right direction. Mostly I want to upload it here because it works now, and without any revision-control solutions of my own I'm scared of screwing it up :)

Edit: no attachment here - scroll down

[poptones]

How hard would it be to integrate DVD2AVI into this? Not the entire interface - just using the MPEG2 front end to allow fast "playing" of MPEG2 files without having to go through "helper" applications and plugins? With the other stuff already added, that seems to me like it would be a great "version 2.0"

[Richard Berg]

You'd have to ask one of the DVD2AVI folks...I've never looked at the code & wouldn't know the first thing about how to write an MPEG2 decoder.

Along similar lines, though, I know there's an "mpeg2dec" plugin floating around -- is it GPL?

Besides the rest of the plugins, I'm trying to think of other things that might need work. Edwin mentioned fixing a few bugs...shouldn't be too hard to patch them in via diff'ing against a clean copy from SourceForge (which I've kept -- saved my butt a couple times).

I'm not sure how old the VDub code is, but I know Avery had to tweak the AVIFileReader classes as recently as a month or two ago to add B-Frame support. BenRG's page mentions that VDub's resize filters are better optimized too, but gosh knows how old that blurb is.

[trbarry]

Some folks use DVD2AVI as a standalone program, without Avisynth.

But as far as Avisynth's use of DVD2AVI is concerned, the DVD2AVI program is just needed to create a project file. This is a tag file created when you do "Save Project" that contains stored options and (mostly) the file offsets to each group of pictures that are needed so Vdub and Avisynth filters can have random access to the file.

But when Avisynth is running the heavy lifting of MPEG2 decoding is actually being done by MPEG2DEC. This needs to read the project file created by DVD2AVI.

I believe there is already a copy of MPEG2DEC source in the save-oe (DVD2AVI) project out in Sourceforge. MPEG2DEC is already an Avisynth filter, but is also sort of dependent upon DVD2AVI changes, at least so far as they affect the format of the project file.

I think some other applications may make assumptions about this file too but I'm not sure of all the implications. But it is important to remember that DVD2AVI must be run once to create the project file before MPEG2DEC can be used. So MPEG2DEC sort of sits between the two applications. We only recently added MPEG2DEC to the save-oe project just because it didn't seem to be in Sourceforge anywhere else, and the version added included ATSC stream support and some P4 optimizations made in parallel with DVD2AVI.

Not sure how all that affects your planning here.

- Tom

[poptones]

So basically it comes down to making the "index" once when running DVD2AVI, or rebuilding it every time the file gets reopened if it were made more a part of avisynth?

Makes sense. I realize people run it standalone, but because it's been borg'd into another code doesn't mean the "regular" version goes away. But it sounds like it may be most optimal just as it is, since spending five minutes reopening the file all the time would suck.

Then again, the file could be created once automatically, and not run again unless something changed... hmmm.

Would it be alright to make MPEG2DEC part of avisynth rather than having to invoke a plugin? Moreover, would there be any speed improvement at all? I've never written a plugin, so forgive me if these questions sound ignorant... they largely are.

[ARDA]

@Richard Berg

Could you please attach an avisynth dll.I couldn't compile it.
I've always get an error with cl.exe when linking.

Thanks in advance ARDA

[Richard Berg]

Darn - you're not the only one apparently. I'll post a binary when I get home, but I'd like to know what's breaking on other people's machines since that's obviously not a good thing. Probably best to attach errors as a text file vs. posting in the thread...thanks...

[dividee]

As Tom said, mpeg2dec is dependent upon dvd2avi. So it's better to keep it in the save-oe(dvd2avi) CVS, and thus as a plugin for avisynth.

Adding d2v creation to mpeg2dec is probably not a good idea: you won't gain much time, just some seconds of manned operations. Furthermore, if YV12 cropping & resizing are added to mpeg2dec, you would need a GUI anyway to choose the values.

Invoking a plugin only involves a LoadPlugin call for the user, and it's easy for the developer too: follow the link to the tutorial on my previous post in this thread for details.

My opinion is that stable plugins may be added to avisynth natively, but filters in development should be kept as plugin. It's easier for the testers and developers to play with 10 different dlls than with 10 different versions of avisynth.dll !

[Richard Berg]

I agree; the actual merging in of plugin after plugin isn't nearly as important as making it possible to do so in the first place (which it should be now). MPEG2 functionality in particular looks like a lot of work with little benefit.

Adding & refining filters will be a continuous project, but I guess the next "big" task is documentation. Not only updating the user guides for new & fixed filters, but some developer docs and inline comments. Chances are they should be checked in with the code (under a different directory perhaps)...HTML is probably best if only because ripping Ben's site would get it off to a good start...

[trbarry]

I don't think there is any noticeable performance hit from loading a plug-in. And I like to be able to specify which one I'm loading. Some version of MPEG2DEC have been hardware specific or test versions and it is a pain to compile Avisynth since it refers to too many libraries.

@Poptones - I think I remember you cursing about this over on Ars a few months ago. ;)

BTW - I think the more up to date Avisynth doc is now on Edwin's site. Wonder if he is willing to add it to SourceForge?

I recently started trying to catch up on Avisynth history by reading the Yahoo forum/list but there are about 500 messages out there. It will take awhile. ;)

- Tom

[poptones]

Yeah, I guess in one respect avisynth has been a good newbie experience, since there's so damn much to get together. It's like you gotta hold your mouth just right when you hit F7.

I just recently started using mpeg2dec. I've been using the japanese vfapi thingie for about a year now, and I'm startled how much faster mpeg2dec is. And I can see how it's fairly trivial to add that one line to the avs, but somehow it still seems inefficient compared to having them talking with one another (slightly more) directly.

BTW I finally managed a compile of all this today, and it's very, very nice. I don't know if anyone else is using this for more sophisticated stuff, but it's become a pretty powerful tool.

[Koepi]

I don't get it to compile due to an (well, 12) error(s) with the asm commands "PREFETCH" and "PREFETCHW" - anybody knows what I'm missing?

Thanks,
Koepi

[dividee]

Maybe the Visual Studio Processor Pack (http://msdn.microsoft.com/vstudio/downloads/ppack/default.asp) ?

[int 21h]

Originally posted by Koepi
I don't get it to compile due to an (well, 12) error(s) with the asm commands "PREFETCH" and "PREFETCHW" - anybody knows what I'm missing?

Thanks,
Koepi

Lemme guess, you are trying to compile with the Intel compiler? or perhaps the other way around? Using the MIcrosoft compiler?

I can't remember which case it is, but one or the other won't recognize those instructions for some reason. It seems to me if I remember right, its related to AMD shiznit, and AFAIK, the VCPP wont fix it.

[Richard Berg]

Originally posted by Koepi
I don't get it to compile due to an (well, 12) error(s) with the asm commands "PREFETCH" and "PREFETCHW" - anybody knows what I'm missing?

Thanks,
Koepi

In decomb.h there is a line #Define ATHLON. Commenting it out will disable it from emitting 3DNow! opcodes, though it shouldn't matter until runtime if you have VS SP5 + ProcPack.

I'm gonna go through and add dividee's Layer fixes. When that works I'll post it to a temporary SourceForge project -- already, versioning is getting to be a mess. The whole idea is that once it's in a source repository, the amount of code you have to check in/out to make a fix is dramatically less than before.

[int 21h]

Originally posted by Richard Berg


In decomb.h there is a line #Define ATHLON. Commenting it out will disable it from emitting 3DNow! opcodes, though it shouldn't matter until runtime if you have VS SP5 + ProcPack.

I'm gonna go through and add dividee's Layer fixes. When that works I'll post it to a temporary SourceForge project -- already, versioning is getting to be a mess. The whole idea is that once it's in a source repository, the amount of code you have to check in/out to make a fix is dramatically less than before.

The Intel compiler doesn't know those 3DNow opcodes, and I think that's the source of his problem, but yea undefining it will fix it.

[Richard Berg]

You're right, I totally skimmed over "Intel" in your post. I've worked with it before (version 5.0 anyway) and it's quite cool, but not quite smart enough yet -- you end up spending just as much time tweaking code until it auto-vectorizes as you would just writing ASM...and I'm not that good at assembler.

Anyway, this post will have the latest complete tree attached shortly...waiting for the latest layer.cpp fixes from poppy. Please report any problems you have compiling (runtime errors are good to know about too, obviously).

[Richard Berg]

Well, I have to wake up early tomorrow so patching in Layer v1.03 will have to wait. Meanwhile, this code should be just as good for testing overall compatibility with everyone's build environments. I'm able to build all 3 versions without errors, but that's not good enough :)

[Koepi]

Thanks mates, it's indeed a problem of the intel compiler.

Didn't help me too much as again (as usual) I get 328 of symbol redifintions on linking, the same as with the CVS of avisynth - and I'm definatly too dumb to configure my build environment right to find where my includes suck ;)

Once again, thanks for your help! :)

Best regards,
Koepi

[Richard Berg]

My list:
C:\Program Files\Microsoft SDK\Include
C:\Program Files\Microsoft Visual Studio\VC98\Include
C:\Program Files\Microsoft Visual Studio\VC98\MFC\Include
C:\Program Files\Microsoft Visual Studio\VC98\ATL\Include
C:\Program Files\Quicktime 5.01 SDK\SDK\CIncludes

Libraries are listed analogously.

I'm using VC++ 6.0 for the forseeable future (basically until I'm sure a majority of others would be able to read VS7 projects) -- VS7 doesn't offer many improvements for C++ developers, though Everett is shaping up very very nicely indeed :)

Anyone else able / not able to compile the ZIP posted a few lines up?

[vlad59]

Hi,

I have exactly the settings you gave (for the include path except for the quicktime stuff) and I get the following errors :

F:\Temp\avisynth\source.cpp(1072) : error C2065: 'IIPDVDec' : undeclared identifier
F:\Temp\avisynth\source.cpp(1072) : error C2065: 'pDVDec' : undeclared identifier
F:\Temp\avisynth\source.cpp(1072) : warning C4552: '*' : operator has no effect; expected operator with side-effect
F:\Temp\avisynth\source.cpp(1074) : error C2227: left of '->put_IPDisplay' must point to class/struct/union
F:\Temp\avisynth\source.cpp(1074) : error C2065: 'DVDECODERRESOLUTION_720x480' : undeclared identifier
F:\Temp\avisynth\source.cpp(1075) : error C2227: left of '->Release' must point to class/struct/union

I was trying to compile it as a release.

I try to check this out.

[int 21h]

That source does not look original.. since when is there a DVDDec class?

Anyways, without the Quicktime thing, I'm pretty sure this wont compile because of the Quicktime source filter.

[Richard Berg]

That source does not look original.. since when is there a DVDDec class?

One too many D's - it's a DV decoder. Dunno when it was added, but untouched from the CVS.

IIPDVDec is defined in strmif.h which is part of the SDK...you probably have an older version.

[ARDA]

@Richard Berg

Quote
________________________________________________________________
Probably best to attach errors as a text file vs. posting in the thread...thanks
________________________________________________________________

I hope with this avisynthplg you can help me.
Thanks ARDA

[vlad59]

@Richard Berg

Yep, I've got this file strmif.h, but in the prerelease directory .....

I commented this DV function and I get new error about :

F:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\unknwn.h(123) : error C2787: 'IMediaControl' : no GUID has been associated with this object

I think it's time to check for a newest version of the SDK. Let's download :D

[ARDA]

As I can see my attachment here I post the most significtive
lines



Performing Custom Build Step on .\convert_a.asm
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000. All rights reserved.
Assembling: convert_a.asm
Compiling resources...
Compiling...


source.cpp
C:\Archivos de programa\Microsoft SDK\include\unknwn.h(123) :
error C2787: 'IMediaControl' : no GUID has been associated with this object
C:\copydvd\avisynth\avisynthberg030702\source.cpp(678) :
see reference to function template instantiation 'long __stdcall IUnknown::
QueryInterface(struct IMediaControl ** )' being compiled


scriptparser.cpp
tokenizer.cpp
Error executing cl.exe.

avisynth.dll - 1 error(s), 0 warning(s)



And If ask the compiler go to error tag:

of an unknwn.h



extern "C++"
{
MIDL_INTERFACE("00000000-0000-0000-C000-000000000046")
IUnknown
{
public:
BEGIN_INTERFACE
virtual HRESULT STDMETHODCALLTYPE QueryInterface(
/* [in] */ REFIID riid,
/* [iid_is][out] */ void __RPC_FAR *__RPC_FAR *ppvObject) = 0;

virtual ULONG STDMETHODCALLTYPE AddRef( void) = 0;

virtual ULONG STDMETHODCALLTYPE Release( void) = 0;

template<class Q>
HRESULT STDMETHODCALLTYPE QueryInterface(Q** pp)
{
return QueryInterface(__uuidof(Q), (void **)pp); // pointing to this line
}

END_INTERFACE
};
} // extern C++
HRESULT STDMETHODCALLTYPE IUnknown_QueryInterface_Proxy(
IUnknown __RPC_FAR * This,
/* [in] */ REFIID riid,
/* [iid_is][out] */ void __RPC_FAR *__RPC_FAR *ppvObject);

void __RPC_STUB IUnknown_QueryInterface_Stub(

[Richard Berg]

Hopefully that's just another instance of needing a newer SDK and not a localization issue (i.e. failing because you're using the Spanish version of Windows), since I know how to fix the former but not the latter.

[Richard Berg]

We're live on SourceForge. Everything should be there -- docs, binaries, code -- except for CVS (I have to wait for a DNS change to propagate).

http://sourceforge.net/projects/avisynth2

[vlad59]

I got the latest Core SDK (XP SP1, May 2002) and I get exactly the same errors.

If I comment the SetMicrosoftDVtoFullResolution, I get the same errors as ARDA.

The new SDK didn't change anything.
@Richard Berg : You talked about latest W2k core sdk, I didn't have the choice on wich sdk I should download, maybe it has an importance...

[Richard Berg]

No, I think that's the exact same SDK I have. Does the help file begin: "Welcome to the Microsoft® Windows® XP Service Pack Beta 1 Edition of the Platform Software Development Kit (SDK) documentation"?

Hrm. Looking up that error message (http://www.google.com/search?cat=&q=see+reference+to+function+template+instantiation) it seems it's associated with some bugs in VC6, which isn't shocking, but the question of why it works for some people and not others remains perplexing.

You sure you have them listed in the same order (SDK first)? The VC98 directories also have the files in question, so if they're being prioritized that would explain why upgrading the SDK did nothing at all.

Edit: any thoughts on whether we should move these types of issues to SourceForge? I'm ok either way, but as a relative newbie to Doom9 it's not my call how much bandwidth they wanna waste on us devs :)

[vlad59]

No, I think that's the exact same SDK I have. Does the help file begin: "Welcome to the Microsoft® Windows® XP Service Pack Beta 1 Edition of the Platform Software Development Kit (SDK) documentation"?

Yep, it seems it's the same SDK.

Hrm. Looking up that error message it seems it's associated with some bugs in VC6, which isn't shocking, but the question of why it works for some people and not others remains perplexing.

Another strange thing is that I don't have strmif.h in my SDK include directory, it's still in the prerelease directory.

I got the same message as ARDA only when I comment all the Microsoft DV stuff.

[Richard Berg]

I don't even have a prelease directory :confused: My copy is totally clean -- I just installed VS6 about a week ago, immediately applied SP5 + ProcPack, and pointed it to the SDK's include & lib directories (see note on the order they appear in the list).

Let's fix this without commenting anything out, especially since that doesn't work...

[vlad59]

Wahoo, you answer really fast ... ;)

Where did you download your SDK ??

Last night I just follow the wizard in Microsoft page, I 've let it uninstall my previous SDK, maybe that's the pb.

I just began de uninstall cleanly the SDK and I will reinstall it afterwards to be sure.

I let you know as soon as the install is done (2 or 3 hours).

EDIT : My include and lib directories are identical to yours (the order too) except for the quicktime SDK, I'll download it today (is it really necessary ???)

[Richard Berg]

QuickTime SDK (ftp://ftp.apple.com/developer/Development_Kits/QT_5.0.1_Win_SDK.zip)

The MS uninstall routine should've been good enough (and frankly an SDK only a year old should be good enough too -- the code in question hasn't been changed in many months), but a fresh start can't hurt.

[Richard Berg]

Note: I've fast-tracked a 2.0.1 release to SourceForge (mostly for a really dumb fix, don't ask; also backed layer.* down one version pending a poptones+dividee merge by someone who knows what they're doing).

[dividee]

I can compile it under VS6 and VS7, using the Platform SDK that came with VS.NET.
And I didn't install the Quicktime SDK. Where is it used ??
I still had one problem for linking (with both VS6 and VS7): by default it doesn't link with convert_a.obj; I solved the problem by adding $(IntDir)\convert_a.obj to the object/library module list. Maybe there is a more elegant way ?

[Richard Berg]

No, that's precisely the stupid bug I mentioned above. I fixed it just before I zipped up 2.0.0...without hitting "save project" in between.

I'm not sure where they're invoked, but the Profile config will always bitch at me unless I add penter.lib and qtmlclient.lib (neither of which is required for the other config, AFAICT) to the Link section. PEnter.lib is in the SDK; the QT one is in QT, obviously.

In other news, the source tree is finally committed to CVS, yay...

[dividee]

Thanks for the clarification, I had never used the profile config.
If I remove qtmlclient.lib from the libraries it links just as well. Can't we get rid of it, and at the same time of the Quicktime SDK ?

[Richard Berg]

Just checked in to CVS:
-generalconvolution's argument syntax is now "c[bias]i[matrix]s" and works as advertised
-layer.cpp/.h include the diffs from dividee's misc.cpp posted to the other thread
-dependence on QuickTime SDK removed

Note to anyone using or planning to use WinCVS: version 1.3 beta 8 is not stable (http://devnet.strata.com/bugzilla/show_bug.cgi?id=780) -- uninstalling it & installing beta 6 did fix the issue (and a couple others I didn't know existed until I saw how much better a stable version was!).

[Koepi]

Richard,

while you're at it:

could you revise the version information included in the dll a little please?
It still shows version 1.7.5e beta, and as address avisynth.sf.net - both should be adopted to refelect the "real" version ;)

Ah, and I placed a feature request into the project's page - I already discussed it a little with dividee a while back, but he may have forgotten about it / lacks the time :) Thanks!

Regards,
Koepi

[Richard Berg]

Thanks, that's what it's there for!

Before I shave 2 fun-filled hours off my life looking for an easy answer, how does one do versioning in DLLs?

Edit: ok, I've assigned it to dividee, hope he doesn't mind :)

I've also added you to the project, Koepi. Dunno what to do with most of the folks on that list, but based on the skills you've shown with XviD, I've gone ahead and given you rights to help release build packages & moderate the forums.

[dividee]

Versioning: just click on the ResourceView in Visual Studio 6 :)

@Koepi: Didn't forget, in fact it was nearly finished and then I dropped it for something else. I'll come back to it soon.

[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.

[dvd2svcd]

Inno Setup is a free (it's free even for commercial use) installer for Windows programs. I never use anything else:

http://www.jrsoftware.org/isinfo.php


Also get the extensions here:

http://www.wintax.nl/isx/

To this day I have never had any installations which couldn't be solved by the above installer.

[sh0dan]

@RB & Dividee: An installer and a plug-in directory sound like a very good solution. An installer would make level-of-entry a lot better - a user who has just unzipped the archive, and doesn't know what to do about the .reg-files doesn't get a good start with avisynth.

Also beginner level documentation should be written (Welcome, installation, virtual dub, sample stuff, etc.). The FAQ is a beginning, but it's still not an easy start. I think we should also set a goal to give the documentation a shine-up before 2.10. I'm still not 100% sure about the Wiki-idea - I kindda like the idea - if just the users are sent there after installation, and there is good, structured information for them, to get them easily started. What I don't like is the complete dependency on being on-line (I for instance only got net-access at work), and perhaps my control-desire - I like CVS very much, and I actually see it as a good tool for keeping the documentation updated.

[poptones]

So who wants to help invent a python plugin?

[Marc FD]

a plugin directory would be something great !
if fact i already thinked at it, i just thought it was not possible because if i thinked of it everyone should have already tried it :D

i experienced loading several plugins via an import .avs is really not a good solution, even more when you do tweaking.
what do you think of an automatic-LoadPlugin("xx")-line-adding in the parser if a function has an unknow name
it could check in an easy-to-change-and-to-update file who would list function names and they .dll librairies

If it's not done by avisynth, i would add it externally for myself, but i think it would be better to add that in avisynth :)

The idea to open avisynth to less experienced users is not bad, but :

1) avisynth is a scripted language, not as user-friendly as a gui
(at least for a n00b , i prefer 10x scripting as a gui :) )

2) they are already several progs generating .avs scripts for encodes.
I think of GKnot, AutoDub, ect...
if you want to use avisynth an easy way, it's not a pb.

3) Avisynth is a _very_ powerfull tool, and i don't think everyone is going to use the most advanced feaures.
I mean someone who really _need_ to use avisynth is not a lambda user who doesn't know anything to digital audio/video world ! He know at least how to use VDub well and is able to write some script lines and to tweak filters.

So, i think making efforts like a user-friendly installer is not a bad thing, but we don't need to focus too much on n00bs who won't use avisynth because they would get much faster what they want if they use a rippack who uses avsynth.

Does this make sense or i totally messed something ??

BTW, when i have good ideas, i always fear an another coder would have the same and that we would wrote very similar code and finally loose lots of time
(ie, i did a lil psnr.dll plugin and when i released it dividee said he was working on something similar, compare() )
It's why it would be really great to have a project announcement page or thread (on doom9/sf/or with the "wikki" thing ?)
Who every avisynth coder could expose is current projects, so other coders won't loose their time writing the same things.they could even propose their help for a project they really like.
I think it would benefit to Avisynth community.

( i assume fs/os projects of course, no videotools.net sh*t )

Thx for reading. sorry if the post is too long.

[Guest]

@WarpEnterprises

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

I already apologized for it.
Imagine too my shock at finding my plugins murdered. :)

@sh0dan

>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.

All you need to do is bundle a list of links with the distribution. That is better than bundling the plugins themselves! You can figure out why, I'm sure. :) Better yet, do as we do for VirtualDub: publish the link to a comprehensive plugins listing at a web site some kind soul will maintain. It's just a bad idea (IMHO) to couple plugins to releases of Avisynth in any way, shape, or form, because the plugin authors lose the ability to update at will.

@Richard

>Frankly, I dunno why nobody (except Avery, that brilliant bastard)
>thought of this before. The concept has my total support.

Actually, for the record, I first suggested the plugins directory to Avery. I had seen it in Adobe Premiere. Nevertheless, Avery's brilliance is manifest.

@all
A new release of Decomb is in beta. It solves the problem of incorrect decimation of frames when the source is from 8fps or 12fps anime (e.g., Princess Mononoke). The solution preserves the decoupling of the Telecide and Decimate filters. Challenge to dividee: how then does Telecide communicate the frame to decimate to Decimate? This new functionality will remove the need to use IVTC22 for these kinds of clips. ;) But better still, the process of IVTC for 3:2 source becomes much faster (because when you are in pattern, Decimate has no work to do; it is told which frame to decimate)! I can now process Telecide.Decimate in real time. This new version is being beta'd by manono and I hope to release it within days.

[stickboy]

Originally posted by Richard Berg
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.Well, I suppose my concern is that the user doesn't always know what he/she is doing. For example, could a malicious developer surreptitiously override the Load* functions with his own? Of course, installing plugins (or software in general) requires some amount of trust in the first place, so I guess it's not really an issue.

[Richard Berg]

A good hacker could already write a plugin that formats your hard drive, or whatever -- Avisynth isn't designed for security :) Barring a major shift in focus I don't think we should bother even pretending otherwise.

@DG - I'm assuming you've seen the updates to Decomb by now; I'll be deleting them from the repository tonight. FWIW old diffs are automatically kept in the "Attic" part of the CVS.

[Guest]

@Richard

Yes, Sir, I've got the diffs now. Thank you very much for the links.

[poptones]

The idea to open avisynth to less experienced users is not bad...

It has nothing at all to do with making it accessible to less experienced users. It has everything to do with evolving the product past "curiosity."

You think it's powerful now? Look into the modules you can get for python - to say nothing of the core functionality. And it's all platform agnostic.

Making this part of python would make the codebase instantly valuable to the python developer community. That means attracting people competent in porting the codebase to linux and mac. Improved quicktime support. Agnostic interprocess communications.

Consider this most basic example: once there is a means to get video into and out of python, those tcp hooks mean interprocess communications now can exist outside the box. Want to use FCP as a graphical front end but would like access to the avisynth toolbox? No problem. Not only does it now run on your mac (because someone finally ported it) but your mac also handles AVIs damn flalwessly - because that part's running over there on the PC. All you need is a simple python script (downloaded off the net, cuz you can be sure somebody'd write one) that exports the video object via TCP, run a script on the mac that imports the object, and now your PC and your mac are sharing render duties. That cheap 2GHz PC is now serving your project in realtime to your FCP project.

BTW, did someone say "render farm?"

Do 3D modelling? Want to make some fantastic titles for your project? No problem - just import one of many python 3d packages or font packages and have at it. Vector graphics and video now exist in the same domain - and you don't need a compiler, or to know c.

BTW, when i have good ideas, i always fear an another coder would have the same and that we would wrote very similar code and finally loose lots of time (ie, i did a lil psnr.dll plugin and when i released it dividee said he was working on something similar, compare() )

This is exactly why you DON'T keep ideas secret. If a more experienced coder than me wants to pick up this ball and run I'll be damn happy to run defense. No offense meant to you, but what you describe is what I call "corporate think." It's not enough to have an idea, you have to take credit for the idea. I never got into that, instead I look at it like this: if I have the idea, and I share the idea, and my idea gets put into action, who benefits? If I come up with an idea and never share it with anyone, and I lack the skills or resources to see it to fruition, who suffers?

This project is definitely over my head. I've been immersed in python and c documentation a couple weeks now, and I'm not sure how much closer I am to getting something working. I kinda think it'll be one of those things that just works one day and I realize "this is how you do it." At least that's what I'm hoping; I'm trying, anyway. And if you like the idea, I would damn sure appreciate the help.

[hakko504]

@Richard

I noted the the original install.reg and uninstall.reg is not included with the 2.0x releases of AVIsynth. This could be a problem if someone new dl's the file and can't make it work on his machine. Could you make sure these files are included in future releases?

[Richard Berg]

I think you'll find a lot of support (count me in!) now that you've cleared up WTF was meant by "So who wants to help invent a python plugin?"

Thoughts:
If we're going to market ourselves to a wider audience -- even an audience of developers -- then it's time to push the project to the point where I can click the checkbox on SourceForge to display "level 5: Stable." I have to imagine a big reason why VDub is so revered is its utter stability; when something goes wrong, nobody thinks twice before blaming it on a codec or plugin. We may not be writing GCC here, but anything that presents itself as a platform has to establish a level of trust in order for people to develop on top of it.

The good news is we're pretty darn close. The only internal bug I've seen reported recently is the Parser one on SourceForge, and that'll be an easy fix. Being feature-complete is just as important, but we're not far off there either: image-sequence importing, compressed audio, and plugin enumeration are the only gaping holes that come to mind, and they're all being worked on with at least two planned for the next big release.

Assuming those get wrapped up, does anyone else see any architectural bugs/features that need to be attacked? There will always be a push to build a better mousetrap (deinterlacer, denoiser, etc.), but when the core is in good shape I'm certainly ready to branch out toward bigger & better things.

[Richard Berg]

Originally posted by hakko504
@Richard

I noted the the original install.reg and uninstall.reg is not included with the 2.0x releases of AVIsynth. This could be a problem if someone new dl's the file and can't make it work on his machine. Could you make sure these files are included in future releases?
They are with 2.00-2.02; blame Klaus ;)

[sh0dan]

@hakko504: Found out 15 minutes after release, where I then added the files - they're in the files at SourgeForge. You're just too fast :)

I was just happy when i saw that nobody had downloaded it, but I see now, that the download-counter isn't updated real-time. ;)

[hakko504]

OK, I dl'd it as soon as I got the mail from Sourceforge telling me the file was available.

Keep up the good works guys. :)

[dividee]

@neuron2
Challenge to dividee: how then does Telecide communicate the frame to decimate to Decimate?
I bet you're challenging me because you read the discussion I had with Sh0dan about ColorSave ;)
I assume you're aware of the different issues that might pop in.
Do you support multiples calls to Telecide/Decimate in the same script? Without the user having to provide a handle?
I can imagine a solution if conveying information along with the clip would be feasible, but there is no place for user data in VideoInfo and it wouldn't be safe anyway.
Using static data... no.
Using SetVar & GetVar ? They wouldn't allow multiples instances of Telecide/Decimate, unless...
What about that:
On first call to Decimate's GetFrame, you set a script-wide variable with the address of some dynamically allocated object. Then you call child->GetFrame. You are now sure that the first instance of Telecide that'll be called will be the one that should pair with this instance of Decimate. Once GetFrame returns you can check some flag set by Telecide just in case Decimate is used alone. Now you have an exclusive communication channel! Some additionnal care might be needed if you want to allow multiple calls along a single path in the filtergraph, but I think it's doable.
To handle strange (rare?) problems that might occur because of avisynth frame caching, I can think of using a bit map with a size of numframes, as the only information you need to convey is a boolean. But there are other solutions for that part.

That was some hard thinking! Is it something along those lines?

[Guest]

@dividee

Yes, that was the reason for the challenge.

It's very simple, you just call my functions SetVideoUserData() and GetVideoUserData(). :)

SetVideoUserData() works like this: On the first video line of the frame, do a standard rearrangement of bytes to bring the Ys, Us, and Vs together. Then do a simple run-length encoding and write that at the start of the video line, preceded by a magic number. Place the user data in the bytes freed at the end of the line. If there is not enough room, just do more lines.

GetVideoUserData() can detect the magic number and know whether there is valid user data there (or the receiving filter can just assume it is there). In any case, the user data is extracted and the video line decompressed and restored. QED.

But for communicating a frame to decimate, you can just write directly over the source pixels, because the frame is going to be discarded anyway. :)

I don't think SetVar() and GetVar() can be reliably synchronized on a per-frame basis.

[Marc FD]

Whow :eek: !
That's something pretty complex :confused: !!
It's seems damn slow too...
if filters are used before decimate, all you're (cool) work would be worthless, no ?
if you aren't going to use filters between them, then just make the first filter add a new info line and the second filter delete this line.

I assume it's a joke ;)

EDIT : no. (!?!) i see i've alot of things to learn more...

[dividee]

@Marc:
I wouldn't assume such things if I were you ;)
Actually your method (adding one line of info) would probably be slower, since it would involve copying the whole frame to a new buffer. A slightly more complex operation on a single line would beat that flat out. RLE compression is faaassst.

@Neuron2:
I was thinking Telecide and Decimate were usable separately. Am I wrong here? (I only used Decomb once, since I usually don't have much use for IVTC; it was on a stream that was heavily edited after telecining, with pattern change every two seconds and missing fields; I was amazed by the result, BTW). What happens if Decimate is not called after Telecide? Also as you require no filter gets called between them, it wouldn't be that hard to synchronize them with my method. The only issue is caching. In fact GetVar & SetVar are only called once (on first frame access) to pass the address of a communication buffer. If user_data is only a couple of bytes, that buffer could be a big array with (numframes) elements of user_data. If user_data is a little bigger (a couple hundred bytes), it could use a smaller structure whose number of elements would still be bigger than the maximum number of frames that could ever gets in the cache, where user_data would be stored along with the frame number in an MRU list. But this is becoming quite complex and maybe too hackish even for my tastes :)
You should work on your plugins instead of reading such nonsense :p

[Guest]

@Marc FD

No joke. Read what dividee wrote.

@dividee

>I was thinking Telecide and Decimate were usable separately.
>What happens if Decimate is not called after Telecide?

They are usable separately. Note that the information passing is only done when guide=1, which means the source is declared to be 3:2 pulldown material, and Decimate is always used in that case. I do provide an option to suppress the marking, however, if someone should want to output field matched 3:2 material undecimated (highly unlikely).

>Also as you require no filter gets called between them...

Yes, that is a harmless restriction in this case. That is why I always refer to "Telecide().Decimate()". :) It does need to be clearly documented, of course.

>it wouldn't be that hard to synchronize them with my method.

Perhaps, but your method is starting to sound complicated, while mine is relatively simple and clean. However, my method does limit one to communicating to only the next filter in the chain, whereas yours *may* not be so limited. Anyway, they're both hacks; we need it in the core (see below).

I get an improvement in IVTC quality and a big speedup for Decomb thanks to this trick. What's to dislike?

@Richard

Maybe a good addition to the core would be real video user data.

[sh0dan]

@neuron:

I haven't looked that much at your code, but couldn't the matter simply being resolved by combining the two commmands into a single command, that constructs an exchange buffer:

"PseudoCode:"

AVSValue __cdecl Decimate::Create_telecine(AVSValue args, void* user_data, IScriptEnvironment* env)
{
unsigned int *filter_transfer = new int[size];
return new Decimate( new Telecine(args[0].AsClip(),filter_transfer),
args[1].AsInt(5), // cycle size
args[2].AsInt(0), // mode
args[3].AsInt(0), // threshold
args[4].AsBool(false), // debug
filter_transfer,
env );
}


Maybe, it should be done somewhere else, so the buffer gets properly destroyed, when the filter is done (it could perhaps be destroyed in the decimate destructor), but would it make sense in theory?

[Wilbert]

@Shodan and others,

Also beginner level documentation should be written (Welcome, installation, virtual dub, sample stuff, etc.). The FAQ is a beginning, but it's still not an easy start.

I agree. Of course the FAQ is not (really) intended as an easy start. We should ask ourselves what a newbie wants to know, and what info must be available. I'm thinking about scripts a la gknot. I'm going on holidays on saturday, so I have plenty of time to think about that while I'm away :)

I'm still not 100% sure about the Wiki-idea - I kindda like the idea - if just the users are sent there after installation, and there is good, structured information for them, to get them easily started. What I don't like is the complete dependency on being on-line (I for instance only got net-access at work).

I don't know a good solution for that, but you can always use the printer at work :) What do you think of the idea that everyone can change the Wiki-stuff? I have the same concerns as WarpEnterprises has http://forum.doom9.org/showthread.php?s=&pagenumber=2. What happens if some drunk guy doesn't like you or me and decides to delete stuff. Is it possible to make backups automatically?

I think we should also set a goal to give the documentation a shine-up before 2.10.

I agree. I'm still waiting till an email conformation that my sf-account is created (how long does that takes?). Btw, you did a very nice job with the filter descriptions. Besides that we should add the missing ones (layer, mask, RGBadjust, greyscale, some other), it is maybe also a good idea to indicate whether the filter works in the 2.xx or in the 1.xx versions because I think that many people (think about the dvd2svcd users)) still use 1.xx.

[sh0dan]

@Wilbert:

I think we should go with wiki for FAQ - it's a great way to keep stuff updated!

We really need a "Getting Started", with information about:
-Installation.
-What is Avisynth.
-Simple sample scripts to opening files in Virtual Dub. (open avi, resizing, colorspace conversions)
-Sample scipts for more advanced stuff.
-Links (avisynth.org, sourceforge, doom9, Donalds filters, other filters)

Regarding filters:
If the layout is ok, it could just be added in HTML - otherwise I've uploaded the filter HTML generator to: http://cultact-server.novi.dk/kpo/avisynth/_docs/index.html The tool you need is also there - it's called PPWIZARD - you need to modify build.bat to reflect your paths. Then you modify the .it-files (in the filters directory), and run build.bat - then the indexes will be updated. If you add a filter, you need to add it to the "includes_(category).ih" and the "includes_alphabetic.ih".

If you don't want to care about this, just post the doc suggestions here, and I'll add it to the documentation.

[Wilbert]

About this "Getting Started", I was also thinking about:

How should you do with AviSynth if your source is:
- dvd rip
- analog/digital capture
Thus for example, not so much about denoising method 1,2,3,...,100. But merely point out that you have to denoise (in case of an analog capture for example), this is a good (not too slow) filter to use, if you want to use other denoising methods have a look these threads ...
For dvd ripping you have to do the basics things mentioned in a g-knot example script. So merely what things you have to do and in what order (which is different for rips, captures, animes). I hope you get the basic idea.

Then you modify the .it-files (in the filters directory),(...)

Ok, I think I see how that works. But what should I modify in the .it-files?

[sh0dan]

A filter file could look like this:


#ifdef get_headers

#define+ filter_name ReduceBy2 / HorizontalReduceBy2 / VerticalReduceBy2
#define+ filter_desc ReduceBy2 reduces the size of each frame by half.
#evaluate+ filter_file "_filespec('basename','<?InputComponent>')"
#define+ filter_arg1 HorizontalReduceBy2(clip)
#define+ filter_arg2 VerticalReduceBy2(clip)
#define+ filter_arg3 ReduceBy2(clip)
#define colorspace_yuy2
#define colorspace_rgb32
#define colorspace_rgb24

#endif

#ifndef include_nofilter_info

#include "filter_templates_top.ih"

<span class="titresmall"><a name="ReduceBy2">HorizontalReduceBy2 / VerticalReduceBy2
/ ReduceBy2</a></span>
<p><tt>HorizontalReduceBy2(</tt><i>clip</i><tt>)</tt> <br>
<tt>VerticalReduceBy2(</tt><i>clip</i><tt>)</tt> <br>
<tt>ReduceBy2(</tt><i>clip</i><tt>)</tt>
</p><p><tt>HorizontalReduceBy2</tt> reduces the horizontal size of each frame by half,
[... more filter html]

#include "filter_templates_bottom.ih"
#endif


The top #definitions are used for the external filter indexes, so these must reflect the filter settings.

The HTML in the middle is the HTML that generates the actual filter HTML file (except top and bottom that is included).

Edit: Oh yearh - and you have to replace '#'-signs with '<?HASH>' - otherwise it thinks it's a command.

[Richard Berg]

What happens if some drunk guy doesn't like you or me and decides to delete stuff. Is it possible to make backups automatically?
All updates are stored as diffs. Just like CVS, in fact, only with a "real" (MySQL) database backend. Hostnames are logged when updates are made, and there's a management interface (http://avisynth.org/admin) to block IP masks if it ever came to that.

Basically, unless SourceForge itself (the SSH, SFTP, or MySQL servers) is compromised, the only person who can do permanent damage is me :)

[Wilbert]

about Wiki:

The text you can put on a page is limited. Right now I can't put more text on the faq-page. We can either:

1) AviSynth Links:
»AviSynth Primer
»AviSynth FAQ part 1
»AviSynth FAQ part 2
»AviSynth Manual
»SourceForge Project
»BenRG's Original Site

but I can't figure out how to do that (I can't edit these links?).

2) Make a subpage for each section of the FAQ seperately (I think I know how to do that). So the main page is the AviSynth FAQ (as it is now) which has five subpages containing the sections.

What do you prefer ?

[Richard Berg]

Yeah, that's the biggest disadvantage of the new layout -- the sidebar code is embedded directly in the template, not in the Wiki database, so only I can edit it. I may try to find a workaround, but my knowledge of PHP is pretty nonexistant :)

For now, just let me know what you want in the left pane and I can edit it manually...my initial thought was that it shouldn't need to be changed much but if it becomes an issue I think I could hack up a solution.

As far as your question -- I think minimizing the number of similar-looking links on the front page is more user friendly for someone trying to find where to start reading; having a primer, manual, and FAQ is already pushing it IMO. A couple of core info pages (e.g. a list of Q&As, a list of filters), with sublinks to more detail, seems best. All this is open to debate though, I'm certainly no expert on this stuff...

[WarpEnterprises]

If the layout is ok, it could just be added in HTML

I think the basic layout is fine and all can be changed directly in the HTML. I'm going to add the missing filters and an indication if a parameter is a named parameter.

[Richard Berg]

Telling which ones are optional (and what they default to) would also be helpful.

[sh0dan]

@WE: Great! Let's get that documentation rocking :)
@RB: Yes, that would be very helpful.

[Wilbert]

@Richard,

As far as your question -- I think minimizing the number of similar-looking links on the front page is more user friendly for someone trying to find where to start reading; having a primer, manual, and FAQ is already pushing it IMO.

I agree.

A couple of core info pages (e.g. a list of Q&As, a list of filters), with sublinks to more detail, seems best.

I will do something like this. I hope I can finish that today.

[sh0dan]

FYI, I just committed some minor documentation updates.

[poptones]

Goddamnit. The server just spat my message because it didn't like me attaching a css for the site. So now I get to repeat everything I just said. Forgive me if this is terse, as I don't feel like saying it all over again.

The left margin whitespace is not needed and ugly. The left margin should be 0px; not 3%. I fixed this in the style sheet and tried to upload it, but tyhe server wouldn't take it. Anyway, it should be easy to fix, no?

in the css:

margin-left: 3%;

should be

margin-left: 0px;

Also the sourceforge icon is 210 pixels wide! The nav banner is already too wide, but the graph forces it even wider. I suggest cutting the graph to 150px and the nav panel to 170px. And reduce the font size! I use an 800x600 screen most of the time, and the letters are ridiculously large. It's like it was made for the blind or something. Even at "smallest" in my browser the text is larger than here on doom9.

[Wilbert]

@Shodan,

FYI, I just committed some minor documentation updates.

If you make changes in the FAQ on CVS can you also change them on Wiki? The FAQ in Wiki is ready now, what do you think of it? (The only difference with CVS is that I changed something in Q21 and Q30.)

[Richard Berg]

Ok I'm done fiddling with the Wiki for tonight. Just browse around, you'll see the changes clearly enough...hopefully the layout no longer offends poptones' sensibilities...

I've fixed a couple bugs of late but don't expect the big commits from me (BitBlt, Mp3Source, automatic plugins) anytime soon -- big project at work has to get done in basically a week, then I'm free.

[sh0dan]

@Richard: As long as you have time to stop by here, you're free to go :)

Very nice work with Wiki - I was gonna say "wow! what a totally cool logo", but then I read the note below. It really rocks.

Hopefully I get the time to add something to wiki too :)

[WarpEnterprises]

Updated the CVS-docu (added all filters I know of, merging with shOdan's latest audio hits).
Some filters are indexed now, but with empty docu. Will add it ASAP.

[Richard Berg]

Note to Wiki folks: I just went through and cleaned up all the existing filter references. When updating from the latest CVS revisions or adding those that aren't there yet, please follow the informal standards now in place:
-First line demonstrates syntax showing the type, name (in italics), optionalness (using brackets), and default value (using C syntax) of all arguments.
-Disable automatic WikiLinking on said first line, but after that, linking to appropriate pages using either WikiLinks or explicit (( )) syntax is a good thing.
-If you reference the variable name in the text, make sure it's written exactly the same and is italicized.
-Etc. etc. you know the drill, make it look nice/consistent/helpful/all that.

[poptones]

Wiki looks really nice, except... a couple of things. To begin, I was wrong, I think about the panel width and it now looks too skinny and cramped.

Can you either email me the php or (better) give me access to fix it myself? I'm ill equipped to do php here at present (my linux box hit the wall just today - hot weather, I think) and my PC don' do no php.

[Richard Berg]

See if you can SSH to avisynth2.sourceforge.net -- there's no option in the SF admin panel to control who can access this so it may work now, or I may have to mark you as a global admin, or it may not be possible at all. Actually, I'm certain you'll be able to get in to your home directory, just dunno about the Avisynth2 group directory below.

The files that control layout are in /home/groups/a/av/avisynth2/tavi/tavi-current/template/avisynth/. Hope your vi skills are well polished :) (Or you can be a wuss like me and load local copies into EditPlus, keeping an SFTP window open for whenever I save a file.)

[WarpEnterprises]

@RB: My access to the wiki is again very slow or doesn't work at all.
Are the changes (some IP thing) you made some time ago still active or got they off?
(Don't know about the others but I've 56k dial-up access only with a dynamic IP, that could make a difference)

[sh0dan]

@WarpE: Just browsed your latest additions, and it just rocks! Keep up the good work! Perhaps you should also add the Filter sections to the overview (as you did with the overview) - how does that sound?
I think the FAQ should be removed, when wiki is ready, and the link in the overview should just point to avisynth.org!

[Wilbert]

I think the FAQ should be removed, when wiki is ready, and the link in the overview should just point to avisynth.org!

Exactly my idea. I will do that if my holiday is over (ten days or so) :)

[Guest]

@sh0dan

Something like your transfer buffer could work (although it too suffers from the impossibility of inserting other filters in between), but I finally decided that the solution of Telecide guiding the decimation is not the best solution, and is not in keeping with the original vision of a decoupled solution. Pattern guidance is just not reliable enough. Telecide can get rid of the combing and you don't see pattern guidance failures, but if you then make wrong decimation decisions as a result, you can see them! So it turned out that it was better to let Decimate make all the decisions. It still amazes me that a fully decoupled solution can work so well.

Thank you for your suggestion. I will keep it in mind for future applications.

[Wilbert]

@Sh0dan, Warpenterprise,

Regarding filters:
If the layout is ok, it could just be added in HTML - otherwise I've uploaded the filter HTML generator to: http://cultact-server.novi.dk/kpo/a...docs/index.html The tool you need is also there - it's called PPWIZARD - you need to modify build.bat to reflect your paths. Then you modify the .it-files (in the filters directory), and run build.bat - then the indexes will be updated. If you add a filter, you need to add it to the "includes_(category).ih" and the "includes_alphabetic.ih".

Done that, automatic html generation works. How do I sent html stuff to sourceforge? How do I update the faq on sourceforge (is there also an it-file for that)? Do I need to install a ssh-client and a cvs-client? I installed both, but I'm having difficulties configuring them.

[WarpEnterprises]

Hi, Wilbert.
1. please don't use automatic HTML generation anymore because the layout seems ok and changes by me (and others) that are made directly to the HTML would get destroyed.

2. The update is made via CVS (the FAQ-html is there too).

3. I use WinCVS and a SSH server I found on the net. The configuration was a little tricky but not really difficult. Maybe you want to mail me your problems?
(I can answer only next weekend - holidays...)

[sh0dan]

Originally posted by Wilbert
@Sh0dan, Warpenterprise,



Done that, automatic html generation works. How do I sent html stuff to sourceforge? How do I update the faq on sourceforge (is there also an it-file for that)? Do I need to install a ssh-client and a cvs-client? I installed both, but I'm having difficulties configuring them.

Too late for that ;) We're using handmade HTML now - it's easier to maintain now that the basic HTML is ok.

I was recommended Tortoise CVS (Search google) that is very easy to use and has good windows integration - it also contains an SSH shell. The only problem I had was that I didn't know I had to type my password in the blank console window, when I added my password.

[Wilbert]

Please check your PM.

[Wilbert]

Ok, I'm trying it with tortoise CVS.
The only problem I had was that I didn't know I had to type my password in the blank console window, when I added my password.
I'm afraid I lost you here, where do you have to type your password (btw, I'm trying to do the CVS checkout by clicking on a dir.).

Is the following settings correct (attached 1.jpg)?

If I press ok, I get the following message (attached 2.jpg). Any idea what is wrong?

edit: I'm behind a firewall, so I have to use the server
cvs-ssh.avisynth2.sourceforge.nl

[sh0dan]

You have to make it use SSH (Internet Secure Shell).

My step-by-step:

1) "CVS Checkout"

2) Fill out like this:
http://cultact-server.novi.dk/kpo/avisynth/t-cvs.jpg

3) When the DOS-window appears, type in your passwd and press enter.

That's it for me!

[WarpEnterprises]

Wilbert, here are some additional sites (on WinCVS but some general stuff too):

http://wxworkshop.sourceforge.net/WinCVS_setup.htm
http://denissov.com/howto/WinCVS_SourceForge.htm
http://www.wincvs.org/ssh.html

To work comfortable you can generate a RSA key which you have to enter in SourceForge and your CVS prog, then you don't need to enter any passwords again.

(My SF.NET >> AccountOptions >> ShellAccountInformation EditKeys)

Try the test-connection described in the pages above first if you have difficulties.