[XviD-devel] Changes in Source <-> Xvid 1.0

[Christoph Lampert]

Hi Radek, hi all,

On Sat, 29 Nov 2003, Radek Czyz wrote:
> > * Let's create a public beta. It doesn't have to be the finished version,
> > it can e.g. have MMX-code missing, or whatever.
> 
> Public beta was discussed ever since the biggest problem - not-working
> 2pass - has been fixed (~2 weeks ago). We've agreed on tommorow.

I didn't say I was trying to be original. I was trying to sum up what I
would like to see happening next.

> I'm sorry to notice that you don't seem to understand what's going on
> either: it's not about having some mmx code or not, it's - for example
> - about having CBR working. CBR wasn't working just some hours ago,
> because it was reading uninitialized memory as S-VOP quantizer
> range. 

Acknowledged. I didn't know that, or rather, I read it on the list, but
didn't remember it was still open. Maybe Michael wasn't either. 

In his mail -I believe- Michael was talking about something
else. Fixing a crashing CBR is absolutely neccessary, no argue about
that. Thanks, btw! And rewring MPEG quant to make it threadsafe is a good
thing too, but not crucial. Again, these are only examples! 

> And no, we didn't break it, it was *never* working in dev-api-4.

Now, please calm down. Noone accused you of breaking things. 

Only, as a very very general statement: rewriting code has chances of
introducing errors, and complete testing takes more time than checking
PSNR for one or a few sequences. I sure know that I introduced some 
errors that way. Michael did. Pete did. You did. Even Skal did. 
Without new code, there would be no progress. It's just a question of
when to take the "risk" and for what. 

> Please just remember that dev-api-4 was not an evolution but
> revolution. Simply moving RC to the core created problems, that's it.

Again, no objection. But that revolution was quite a while ago, and if
_still_ that big and earlier unnoticed problems of the dev-api-3 to
dev-api-4 migration pop up, maybe it's not time for a release at all.  

Until recently I had the impression that dev-api-4 worked quite well, at
least I didn't have any problems. Okay, I didn't use all of the extended
features. Still, I believe that not all problems were from the revolution,
but some of the problems were selfmade. Which is okay, and part of
progress, but the closer to a release we come, the less risk we should
take that any more of those appear. 

 
> I was able to encode two movies with api-4 so far and the results of
> last one are very good. Users are still reporting quite big problems,
> but I often have trouble re-creating them. Public beta is supposed to
> help.
> I also found a guy nicknamed Haali who volunteered to code the win32
> GUI. If everything works out, I'll have the first version on Tuesday.
> 
> After that, only bughunting remains. There are still some limitations
> but I don't see how they can be fixed without another revolution, so
> we'll just live with them.

That's part of what I meant with letting everybody finish. Since my memory
had leaked CBR, I thought the "big" problems were done, and everybody
(including me at home) had started on the "also, but not just as big"
problems. 

> PS I just rememebred a good example: VOP type decision was supposed to
> relay on a simple ME. In CVS head, the ME doesn't work at all (the
> only vector checked is 0,0 , always) yet the results are quite good,
> noone even knows about the bug. It never crashes or anything like
> that.
> Do we concider this code stable? It's a matter of definition I guess.

Very good example. Definitely a bug. What was the effect of it?
Inferior VOP type decision. Not buggy streams, not image problems, but
less efficient coding than possible. 
Now, how would I fix it? Depends on where the error lies, of course. If
it's a single line, some wrong value in miniME, change that. Great! Gone
it is. 
But if it isn't, if a whole rewrite of the ME is needed, then _maybe_ that
close before the release or beta, it would be better to leave it as it is
(live with a bug) or call full ME (slowdown) than to replace large parts
of code by not or less tested ones which _could_ introduce other problems. 
Fixing it and spending time on additional bughunting or rewriting miniME
in a local branch, and doing it when the release is out. There is no
"true" answer to what is better, we simply have to agree on something.

gruel