[M4IF Technotes] FW: Quarter-pel AMV problem - what have deployed Advanced Simple code cs done?

[Rob Koenen]

Forward on behalf of Kris Huber who had trouble posting - hope this does
work.
Rob
----------------------------------------------------------------------------
-
Hello all,
I recently discovered what I consider an error in probably all versions of
the MPEG-4 visual reference software to date that implement quarter-pel
motion compensation.  The problem is that the AMV (average motion
vector)
used for further motion vector coding after a GMC macroblock, is clipped to
a range that is half the quarter-pel MV range.  I noticed today that the
same problem, plus some other related issues, were reported in the most
recent "List of MPEG-4 Visual Problem Reports" MPEG document.  That item was
reporting a problem in the OptSimple code, but my searching found the
corresponding location in the Microsoft 12/13/2000 code where incorrect GMC
AVM clipping is performed.  Note that the title of the item that reports
this mentioned interlace, but it also reports several issues.  None of those
issues are confirmed or resolved in discussions that I've been involved with
to date.
The dilema is how this should be resolved.  To promote highly-efficient
interoperable information coding (not to mention causing fewer headaches to
future consumers, engineers, and anyone else expecting interoperability to
mean that the same bitstream will play on all conformant decoders), I think
the wise course is to give the most weight to how the issue was resolved in
the implementations currently deployed.  This is a technical issue that
cannot be avoided in Advanced Simple Profile implementations.  Some things
to consider are:
 - To the best of my knowledge the behavior is the same in all current
versions of reference software, but does not match the text of the visual
spec.
 - AMV problem will not impact coding efficiency of S(GMC)-VOPs more than a
small (negligible) increase in proportion of motion vector prediction bits.
 - AMV problem impacts B-VOP coding efficiency due to modified temporal
prediction in direct mode.  Again, since most of probability for motion
vectors is typically around a small range, coding efficiency is not
compromised by the current reference software.
 - the current behavior of reference software was used during verification
testing.
Please respond if you have information about the details in these respects
about implementations that are deployed or coming close to that stage. If
you prefer to remain anonymous, reply to me directly and I will summarize
results to the list without your company name included (or I'm sure Rob
Koenen would do you the favor).  Gathering such information can be helpful
so this ambiguity of specification can be resolved in an way accomodating to
all concerned.  Without further information, I favor resolving the issue by
changing the text through corrigendum to match the reference software.
Best regards and thanks,
Kris Huber