[XviD-devel] Changes to get_pmv2

[Tom Jacobs]

thanks

i think i got the prediction and MV bit now, and yes i see how the
prediction need to be correct since they are recalculated in the decoder.

so if i set it up so that the main searches are done in parallel with the
wrong predictions i can then, in serial, add the wrong predictions to the
differential MV and then subtract the correct prediction. would this work?

thanskd for the other suggestions and i am not just ignoring them but i am
trying to fine grain parall xvid, ive already done it with mpeg2.

Thanks

Tom



Quoting Christoph Lampert <chl at math.uni-bonn.de>:

> 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
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>