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

[Michael Militzer]

Hi,

Quoting Edouard Gomez <ed.gomez at free.fr>:

> Michael Militzer (michael at xvid.org) wrote something that looks to me
> like:
> > blah blah release 1.0 blah blah blah feature freeze ... blah blah we
> > go away from that objective...
> 
> <rant>
> Ok, you give your opinion, i will give mine, and i take the risk to
> start a flame war:
>  - if it was for me, 1.0 alpha or betas would have been been out in
>    August/September. I release bins since early october.

ok, and?

>  - if feature freeze was really that important for you, you would have
>    never commited new qpel, cartoon or fast mode decision/refinement.

Well, I'd like to point out that 'porting the stuff from the Isibaar
branch to dev-api-4' was/is part of the todo list everyone agreed on be-
fore we announced the feature freeze. I admit I was late in working
on my todo list, but better late than never as the german proverb says.
If that's not appreciated, ok then.

> ... and finally
>  - if it was for me, i would not care of what you say because the only
>    things you told me during the dev-api-4 development is: "hmmm wait
>    no don't do that" or "" (<-- this is a silence). Obviously that
>    doesn't help getting a good XviD 1.0 ASAP. That just helps having a
>    flawed XviD 1.0 whith known long standing bugs.

ok, I'm busy myself with many things. Unfortunately this doesn't leave me
much time to actually work on open issues but only to read my mail and
answer from time to time when I think that I should give advice. I'm
sorry if my advice is just 'don't do that' for you. I may point out that
I adviced you not to include skal's idct (mmx,sse, sse2) code into XviD.
Yes, this was again a: 'don't do that' but if skal's idct would be used
by XviD 1.0, then 1.0 wouldn't play any of the old XviD movies prior to
1.0 correctly - does anyone wants this? No. And so I think that my
comments are helpful to get a good XviD 1.0, even though my free-time is
often only enough to quickly shout: 'no' when needed. If you don't take
this serious anyway or if that's not appreciated, I'll just shut up
then, no problem.
 
> Don't get me  wrong, i've nothing against you but i  dislike the way you
> block important  bugfixes and consequently,  a good XviD  progress. Pete
> did a fair amount of work in  the early days of devapi4, now he will not
> contribute regurlarly afaik.  It's mostly for 4 months  syskin and I are
> the only  active devs.  If  you wanted a clean/bugfree/stable  XviD 1.0,
> you  would have  squashed bugs,  test new  stuff, and  give  feedback on
> proposed changes.
>

ok yes, my last valuable contributions were 3 months ago. I'm sorry for
that but my time is limited. However I think I can still participate on the
ongoing discussions - if you interprete this just as 'blocking' all the
valuable progress, I can't help that. First of all, I did never block
anything (even though I could) but you were always free to do whatever you
liked (that's true for everyone here - and often things got committed
even though I said no and that's fine with me). Sure I said 'no' or 'do we
really need this?' to many things you suggested or were working on - but do
you really believe that everything that you did in the past two months was
just absolutely crucial for a good XviD 1.0 and I was always wrong?

> If you  want to have  a poor  XviD 1.0 with  buggy code and  known flaws
> coming from a 1 year old cvs version... fine but i'm not happy with your
> choice.

I already explained that I don't have no problem at all with _fixing_ a
bug.

bye,
Michael

PS: Find attached a patch that removes the global variables for the
matrices and turns them into a new parameter for the mpeg quant code. The
integration into the rest of XviD code isn't nice, but it seems to work.
This is just a 'prove of concept' that the existing code can easily be
changed to do what we want in just a few hours. Please also note that I
tried to verify the code with the fdam reference software but wasn't able
to do so, because fdam crashes before even the first keyframe gets de-
coded. This problem is not caused by this patch but exists already in
the current cvs version. So it seems we have another serious problem
(looks like wrong bitstream headers at first glance) and iirc dev-api-4
could be decoded with fdam some months ago...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.tar.gz
Type: application/x-gzip-compressed
Size: 12979 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20031129/63c5c3f5/patch.tar-0001.bin