[XviD-devel] Changes to get_pmv2

Christoph Lampert chl at math.uni-bonn.de
Wed Sep 22 14:05:04 CEST 2004


On Wed, 22 Sep 2004, Radek Czyz wrote:
> Tom Jacobs wrote:
> > hi
> > 
> > in ME is just just the MV for each block that is stored in the bitstream or
> > is somehow the prediction there too?

Not the MV for the block itself is stored to the bitstream, but the 
differential MV, that is     MV minus prediction. 
When decoding, the predictor is calculated from the previous MVs (if there 
are any, otherwise it's set to 0), and the predictor plus the value from 
the bitstream make the current MV (which then is use for the next blocks 
etc.)

> > if a full search is taking place how does the predictions matter? does the
> > prediction act as a centre for the search window?

That as well, yes. In a way it's the origin for the next MV. 

> > when the image is decoded does it just use the MV from the MB itself or does
> > it look at the neighbours or prediction (if saved).

Both. see above. 

> > im not sure about the differential vector, is this what is actually sorted?

sorted? 

> > i know thats alot of questions in one go but am trying to get my head around
> > what exactly is happening so i can better what i have to do and what can be
> > done in parallel
> > 
> > Thanks
> > 
> > Tom
> 
> Hi,
> The prediction is also used to calculate how many bits a motion vector 
> will take in a bitstream. Therefore, even at full search, it's pretty 
> much neccessary to have it.

That's what I meant when I said that using a wrong predictor during the 
search process will hurt compression performance a little. You will ME 
will find different vectors as "optimal", and possible they will be a 
little bit worse than the one from original ME. 
 
> Why won't you parallize b-frames first? Any row of any b-frame can be 
> done in any order, so you can easly divide arbitrary number of b-frames 
> into arbitrary number of threads. In 1.1, there is VHQ for b-frames, so 
> I'm pretty sure ME is slow enough to make it worthy.

Okay, B-frames are a better playing field for speedup than normal ME, 
because prediction is much simpler. Good idea! Of a real speedup, I'm 
still not sure, though. 
I would rather suggest to use create a multithreaded encoder queue, so for 
one thing, color conversion/pre-/postprocessing etc. runs in parallel with 
encoding, and in the long run, different scenes (i.e. the segments between 
two I-VOPs) will be encoded in parallel. The coarses, the better. 

chl


More information about the XviD-devel mailing list