[XviD-devel] [In progress] devapi4 -- mpeg matrices

[Radek Czyz]

Hello Michael,

I can't help noticing that you expect XviD to reach 1.0 without its
code being changed.
As far as I understood, our goal was to take very part that doesn't
work and make it working - one by one. You must realize that this is
exactly what we (GomGom mostly) are doing - yet you criticize our
work. If you expect us to do something else than that, you should tell
us.

You wrote:
> Later on we introduced custom matrices and in order to adopt
> the quant code to this change, we introduced the quant matrices as
> global variables just as a quick hack until someone adopts the code to
> accept the quant matrices as function parameters. Now I think that the
> modification that is needed to turn a global variable into a parameter
> doesn't necessarily require to completely replace/rewrite the whole
> quantization code (c, mmx, xmm, 3dn + equivalent h.263 quant code).

What's wrong in making it right this time? Hacks that fix hacks are not
necessary safer imho.. especially when the code in question can be
easly proven to be correct, just by comparing psnr.

> What just concerns me is that we've been replacing huge amounts of code
> in dev-api-4 by newly rewritten/beautified/no tested code without a real
> need to do so (ME split, 2pass rewrite, now the quant code replacement).

You must know that dev-api-4 IS not tested and buggy code. How do you
expect it to change without rewriting the parts that don't work?
I also can't help noticing that you don't care I fixed several bugs
during the ME split, but you complain about a simple typo that was
detected as soon as someone used the option concerned. Do you actually
mean to say it was better to keep the buggy code?

Same goes to RC - if it didn't work in dev-api-4 at all, how keeping
it was better?

> Now we're on the road to XviD 1.0 which should become our
> first official _stable_ release and we're again and again removing stable
> code from the XviD code base and replace it by completely different and
> not at all as thoroughly-tested code

Really, how removing a code that is KNOWN to be buggy is wrong for
stable release? Do you really want to add a list of known bugs to 1.0?
With an explaination "it has been buggy for so long, you probably
remember not to do this and this and this" ?

> In result this means, that all newly introduced code needs special testing
> in a public beta testing phase:

Of course. Nothing strange about this I hope.

There were only two ways: document all the things that didn't work in
dev-api-3 and relase api-3 as stable, or fix them. There is nothing in
between. Since you have chosen the second option, I see no way but
finishing the second option, simply because dev-api-4 doesn't work *at
all* without it.


Best regards,
Radek