[XviD-devel] Changes to get_pmv2

[Tom Jacobs]

hi

in ME is just just the MV for each block that is stored in the bitstream or
is somehow the prediction there too?
if a full search is taking place how does the predictions matter? does the
prediction act as a centre for the search window?
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).
im not sure about the differential vector, is this what is actually 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


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

> Hi,
>
> On Mon, 20 Sep 2004, Tom Jacobs wrote:
> > thank you guel. i will try this.
>
> It's gruel with an 'r'. What's "guel" supposed to be? Never heard of
> it.;-]
>
> >  if understand right, to give it a wrong prediction for the left
> macroblock
> > i can, in get_pmv2, return zeroMV when it looks for the left block.
> this
> > would make the prediction ignore the block, cos it hasnt got a vector.
>
> If you return zeroMV, it will _not_ ignore that block, but it will treat
> it as a block with zero motion, like an INTRA-block. That'll make
> prediction worse, but possibly not too much. It would however be better
> to
> use some other vector instead of 0, e.g. top-left or so.
>
>
> > doing this will not stop the calculated prediction from being stored in
> the
> > bitstream and from being used when the next row is being calculated.
>
> What do you mean by that?
>
> > or have i confused myself?
> >
> > or would you need to call get_pmv2 again block my block (in serial)
> after
> > the searches have been (in parallel)
>
> That it is. The predictor (Data->predMV) will be set to the wrong values,
> therefore the differential motion vector (=MV-predictor) is wrong. That
> has to be corrected before writing the bitstream, either in a separate
> loop, or, you have to call the correct get_pmv2() within the bitstream
> writing process again.
>
> gruel
>
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>