[M4IF Technotes] MPEG-4 quarter-pel motion compensation

[Larry Pearlstein]

Dear MPEG-4 colleagues,
I am confused about MPEG-4 quarter-pel motion compensation.  I'm not sure
that the standard agrees with the Microsoft implementation.  I did not look
at the MoMuSys implementation.
In discussing my concern, I will refer to the figure below:
 <<...OLE_Obj...>> 
The features are intended to convey the following information:
	filled in black circles - represent actual pixel values in reference
picture
	open black (or gray) circles - represent prediction values that
would arise from vertical or horizontal motion offset by exactly 1/2 pel
(i.e. one dimension has offset = 1/2, other dimension has offset = 0).
	open black square - represents prediction value that would arise
from both vertical and horizontal motion offset of 1/2
	X - represents prediction values where either or both of the
vertical and horizontal offsets are not integer, or 1/2.
		black X - represent prediction values where I believe that
the Microsoft reference code matches the spec
		red bold X - represents prediction values where the
Microsoft reference code does not match my understanding of the spec.
My interpretation of the spec is that the open circle positions and the open
square position should be computed by applying the 8-tap horizontal filter
(where appropriate), rounding and clipping, the applying the 8-tap vertical
filter (where appropriate) followed by rounding and clipping.
Then, each of the 'X' positions should be computed via bilinear
interpolation based on circle or square positions, followed by rounding.
The Microsoft implementation only implements two passes.  First a horizontal
pass which does 8-tap filtering, round and clip, followed by bilinear
interpolation for horizontal offsets of 1/4 and 3/4.  Then a vertical pass
which does 8-tap filtering, round and clip, followed by bilinear
interpolation for vertical offsets of 1/4 and 3/4.
Although the linear operations of 8-tap filtering and bilinear filtering,
both vertically and horizontally, are commutative, the non-linear steps of
rounding and clipping, required by the specification, may not permit
commutation of operations.  In particular, it seems that the specification
requires that the offsets marked by the red X's be computed based on
bilinear operation involving the open-square value.  This is not being done
in the Microsoft implementation.
Comments, help?
				Thanks,
				Larry Pearlstein
				ATI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20011008/e12ffa0f/attachment.html