[XviD-devel] Changes to get_pmv2

Tom Jacobs T.R.Jacobs at lboro.ac.uk
Mon Sep 20 20:22:20 CEST 2004


hi

am I correct in thinking:

get_pmv2 sets predMV,  the predicted MV
SEARCH taking in this prediction and set the &pMB->pmvs[*]

if I make get_pmv2 use top left instead of left then it will give me a wrong 
predMV and hence a wrong pmvs

are you saying that it is ok for pmvs to be wrong but I need to correct 
what? I obviously don't want to have to run SEARCH again since this is the 
main saving through parallelising it.

sorry my depth of knowledge as to what exactly is going and what get written 
to the bitstream isn't the greatest.

thanks for your help gruel

Tom






----- Original Message ----- 
From: "Christoph Lampert" <chl at math.uni-bonn.de>
To: <xvid-devel at xvid.org>
Sent: Monday, September 20, 2004 5:46 PM
Subject: Re: [XviD-devel] Changes to get_pmv2


> 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
> 




More information about the XviD-devel mailing list