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

[Prabhudev Hosur]

Dear Gary and all,
The document seems to be correct. I think it is the the reference software
that needs to be changed to fit what document says.
So the sw_int reflector may also be suitable for this discussion
Regards,
Prabhu
-----Original Message-----
From: technotes-admin   lists.m4if.org
[mailto:technotes-admin   lists.m4if.org]On Behalf Of Gary Sullivan
Sent: Thursday, October 11, 2023 6:40 PM
To: Larry Pearlstein; M4IF TechNotes
Subject: RE: [M4IF Technotes] MPEG-4 quarter-pel motion compensation
I've investigated this off-reflector with Mathias Wien and Simon Winder.
It seems that this is a correct report of a problem in the MPEG-4 Visual
specification -- the quarter-pel motion in the document is different from
what is in the software.  Both versions of software are the same, but they
differ from what is in the document.  We plan to add this to the list of
problem reports for MPEG-4 Visual and it will be considered by MPEG
at its next meeting.  The expected outcome at this time is to work
toward changing the document to fit what the software is doing.
-Gary Sullivan
-----Original Message-----
From: Larry Pearlstein [mailto:lpearlst   ati.com] 
Sent: Monday, October 08, 2023 3:10 PM
To: 'M4IF TechNotes'
Subject: [M4IF Technotes] MPEG-4 quarter-pel motion compensation
/* It seems that the drawing in my previous EMAIL did not make it */ 
/* This is a resend with the drawing replaced by ASCII art              */ 
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" reference software
implementation.  I did not look at the MoMuSys implementation.  I'm using
the software in WG11 document n4278.
In discussing my concern, I will refer to the figure below: 
       0   1/4  1/2  3/4 
 0     p    x    o    x    p 
1/4    x    X    x    X 
1/2    o    X    c    X    o 
3/4    x    X    x    X 
       p    x    o    x    p 
The features are intended to convey the following information: 
  p - represent actual pixel values in reference picture 
  o - 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).
  c - represents prediction value that would arise from both vertical and
horizontal motion offset of 1/2 
  x or X - represents prediction values where either or both of the vertical
and horizontal offsets are not integer, or 1/2.
    x - represent prediction values where the Microsoft reference code
matches my understanding of the spec 
    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' or '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 --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 13564 bytes
Desc: not available
Url : /pipermail/mp4-tech/attachments/20011015/1c6bf59e/winmail.bin