[esby]

mmm @dp_sun

I'll just comment some of the changes in the version you have created.
since i'm merely an user here, and not one of the developper.

- VirtualDub-like version numbering scheme. Version is written in the output avi file.
That's not a version numbering scheme, that s build numbering one.
And more exactly that's the date of when you compiled this source,
and does not tell anyone which version was used.
So so far, I think it is just useless, and more confusing,
since you'll still need the version number to make a difference.
Version != Build number
but Version written in the output avi might be still ok.
that's auth info after all.



- Removed buggy matroska and log file output (sorry, guys).
Well I can only agree for mastroka, but:
Removing it was not a priority.
People might still be using it, despite what you think.
For logs, I don't know, I never used this option.
But the same remark applies here.

- Registry entries for DIVX and XVID parameters. The program is now tuned to work with these two.
Well using registry with DIVX is not a bad idea,
some people might like it.
Now, I have looked on the code a bit, and pondered the meaning of 'tuned to work' with these two.
If means added extra support for these two codec, I answer ok, why not...
But if it means only XVID & DIVX codec can be used to avs2avi now, I said a definitely NO!
Some people might use avs2avi with other codecs like ffvfw, huff, rvble, and what god know what they could need.
Using such or such codec is their choice, not yours to limit it to a selection of what you use.

- Parameters specific to the codec and avi file (Max Keyframe Interval, etc.)...
are you talking of the members of the COMPVAR structure...?
are you talking of specifying them via commandline or any other way?
Is this really useful, since you can generate dumpcodecfile already?
and since the codecs are different, some of these parameters
might have no meaning out of your context of use.

I have nothing to say for the rest of your change,
as long they are properly done,
but in that case I cannot really talk , it's more up to Moitah or Rainy.

Although I can add a bit of sarcastic comment here too...
directly from your code:
//#ifndef ABOVE_NORMAL_PRIORITY_CLASS
//#define ABOVE_NORMAL_PRIORITY_CLASS 0x00008000; // Yes you should update your platform SDK.
//#endif
Commenting out this because it is not needed with your platform
is not the proper way to code...
So far, if you did not comment out, forget my remark,
but if you did, think that the developper platform might not be always the same, and stuff like that can cause havoc to others to have it compile or work normally once compiled.
And especially here since it's a #ifndef ...

And to conclude the FILE_ID.DIZ being in the zip file...
I don't care about it,
but if you put such file, AT LEAST put the GPL licence too...
And don't forget that WAREZ has nothing to do here.


So far, my conclusion
(which is personnal and might or might not reflect other people opinion here):

Some of your changes might be needed or ok.
Some are useless, too specific.
Some could have been done directly as bugfix by moitah or rainly...
Since there is no cvs structure for avs2avi,
and that there are at least two different approach actually(not counting yours), with the normal way and rainy client,
avoid to do a huge list of change, unless you want to disturb the actual developper, or present it directly, and in an exploitable way.

Of course, you can modify it, since it's GPL, but don't forget that people are working on it, and don't do twice the job they could do...

on another note,
how about a sourceforge page for avs2avi?
or is it already done?

esby