[XviD-devel] Changes to get_pmv2

[Christoph Lampert]

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