[XviD-devel] Changes to get_pmv2

[Christoph Lampert]

On Thu, 2 Sep 2004, Edouard Gomez wrote:
> > i cant say i understand the reasoning for the locations used in get_pmv2 or
> > why certain mvs[] are read and cos of that this probably cant be done but
> > it would help me
> 
> get_pmv2 returns the predicted motion vector as described in
> the MPEG4 standard. We can't change the way it works.
> 
> PS: though i'm mostly sure of what i've said, i must admit
> i've always been confused by get_pmv/get_pmv2 similiraties, so
> maybe i'm wrong. in that case, correct me.

There is no get_pmv() anymore, only get_pmv2(). As Edouard correctly
states, that calculates the MPEG4 motion vector predictor and its modus
operandi cannot be changed (nor would there reason to change it, since the 
prediction works very well). 

There once used to be a get_pmv() routine for that purpose, but long ago 
that had been replaced by a faster version which does exactly the same, 
only in a completely different way. For a while, both version were in the 
code, so I had to come up with a different name for the new version. Okay, 
calling is "get_pmv2" was not very original, but it served the purpose. 
After we verified that get_pmv2 really behaved identical to get_pmv, we 
only kept the faster version, but didn't change the name. Voila, no 
confusion anymore. 

gruel

P.S. The MVs are read in the following way: You would like to predict a 
block MV from its neighbours  all direction: top, bottom, left and right. 
However, when scanning through the blocks in reading order, you don't have 
the information from the right and the bottom, yet, so you choose left and 
top, and in addition include top-right, which is the "most right" 
neighbour that is available at that time. 
All the rest of get_pmv2() only deals with the question of when to do 
when some of these neighbours aren't available, etc. 

chl