[XviD-devel] [In progress] devapi4 -- mpeg matrices
Edouard Gomez
ed.gomez at free.fr
Fri Nov 28 14:56:22 CET 2003
Michael Militzer (michael at xvid.org) wrote:
> > h263 is identical. mpeg will be identical too once i reintroduce the
> > RD optimized bias.
>
> ok, so obviously the new code is _not_ identical after all - so do you
> have any clue at all why it's different ?
Fixed point computing probably.
Old mpeg code was using real division and ... let's see old h263...
- the 1/2q division used a 16 bit precision with a +1 bias, now it uses
15bit precision with +0 bias
I'll check if changing this generates same bitstream later.
> Now that the new code behaves different: do you have any prove that
> it's really better?
Quality wise, see next answer. Thread/instance wise, now it's *safe*, so
it's better.
Let's explain again the problem:
- xvid shares a single matrix slot amongst all instances (encoders or
decoders). So the code is full of data races at the de/quant stage.
eg: create two encoder instances using MPEG quant. One with default (e1)
matrix (passing NULL), the other with a custom one (e2). Let's say to
simplify the problem that the encoders usage is serialized and not
threaded.
First frame is encoded with e1, thus the matrices are not written to the
bitstream because they're the default ones. So far so good. e2 encodes
its first frame, changes the shared matrix slots, and write a correct
bitstream.
Then e1 encodes its second frame, using the slot matrix set by e2, as
e1 uses default matrices, e1 will never set back the matrix slot to the
default ones. => quality bug. And at next IFrame, VOL will be changed,
because it will write the custom matrices to the bitstream. => spec
violated => VOL must be the same along the complete sequence.
the only good point is that e2 encodes its stuff correctly.
When playing with multithreaded apps, it's even worse the matrix change
can happen at any moment within a frame, especially on high freq
scheduling OSes (where the context switching time is ~<= frame
quantization duration).
The same problem appears when using serialized or threaded instances of
both decoders and encoders.
> You've tested with just _one_ sequence where you reached a 0.08 dB
> gain - do you know how it performs on other scenes? Will it be an
> overall win or not? Was the filesize identical to the old code btw?
Patience Michael, i can't go that fast, if i do all my tests with the C
version, i'd have to wait for too long (~2hours) before continuing with
coding. Give me time, i'll give you results.
--
Edouard Gomez
More information about the XviD-devel
mailing list