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

[Radek Czyz]

Hi again,

Christoph wrote:

> I see the thing as follows: The question is "What is XviD 1.0 supposed to
> be?"

Yes I agree. I admit that there is one thing I've taken for granted:
that the course created by dev-api-4 is the official one.

Dev-api-4 was a big step, or even a couple of steps and I didn's agree
with some of them. However, it had a simple direction: make everything
the way a user expects it - remove some worse hacks; make the libarary
at least consistent with *own* api; move 2-pass code to the core; remove
the parts of the code that were dead and/or worked by accident.
Finally, at least *pretend* that we have an idea how internal
structures are supposed to work.
In short: fix the problems which couldn't be fixed in less painful
way.

If we didn't want any of this (for now), I'd say that CVS head was
simply perfect: it's rock solid, noone has *any* unexpected problems,
the encoding results are very good. Sure the code is illogical, sure
it doesn't work under linux (and that's fixable), sure it has a big
list of known limitations - but it works like charm.

Since we dropped this code, I assumed this is not our goal - that it's
not what we want for 1.0.

Dev-api-4 had a long way to reach the usability of cvs head. Gom didn't
beautiful the 2pass code - he make it *working*. Just pasting the code
from VfW to core didn't mean that it will work, simply because big
parts of it worked completely by accident. There was no way to keep
the same code under different conditions and have the accidents still
the same way.

Same went for lumimasking. Same for CBR. Same for main loop. Etc etc.

Believe me Michael, we didn't do any of this just for fun. It's not
amusing to recreate usability that we already had in api3. But we all
see that this step was needed and important, and everything will be
much easier once it's done.

> * 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'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.
And no, we didn't break it, it was *never* working in dev-api-4.

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


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.


Radek

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.