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.