[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