Chroma motion vector incorrectly scaled

[GoogleCodeExporter]

In the latest VP9 decoder code (actually previous code as well), when the 
resolution of the current frame is different from the reference frame, MV needs 
to be scaled. the code first calls clamp_mv_to_umv_border_sb function to 
convert MV to 1/16 pel precision. The returned MV will be different for luma 
plane and chroma plane. then the vp9_scale_mv function is called to scale the 
MV based on the scaling ratio and then the block offset is added. However, the 
block offset is the same for both luma plane and chroma plane in this function, 
which seems odd. should x_off_q4/y_off_q4 be scaled differently for luma and 
chroma plane because the same block will have different coordinates in luma and 
chroma planes? what is the expected behavior in design?
const MV mv_q4 = clamp_mv_to_umv_border_sb(xd, &mv, bw, bh,
                                               pd->subsampling_x,
                                               pd->subsampling_y);

...........

MV32 vp9_scale_mv(const MV *mv, int x, int y, const struct scale_factors *sf) {
  const int x_off_q4 = scaled_x(x << SUBPEL_BITS, sf) & SUBPEL_MASK;
  const int y_off_q4 = scaled_y(y << SUBPEL_BITS, sf) & SUBPEL_MASK;
  const MV32 res = {
    scaled_y(mv->row, sf) + y_off_q4,
    scaled_x(mv->col, sf) + x_off_q4
  };
  return res;
}

Original issue reported on code.google.com by agra...@google.com on 27 Jun 2014 at 3:23

[GoogleCodeExporter]

vp9_scale_mv uses the (x,y) position of the block to compute the fractional 
position in the reference frame. It then adds this fractional part to the 
scaled motion vector to get the co-ordinate of the matching block in the 
reference frame.

The issue is that the values of x & y sent in to this function are incorrect 
for the chroma planes. The calling functions do not take into account the 
chroma subsampling factors and send in the block position in Y-plane 
co-ordinates.

The fix should take into account the chroma subsampling factors.

The resulting bug will result in an incorrect fractional pixel position being 
calculated for non-4:4:4 frames. Also need to check the non-scaled path to 
ensure there is not a similar issue.

Original comment by agra...@google.com on 27 Jun 2014 at 3:31

[GoogleCodeExporter]

After evaluating the effect of this issue we decided that the effect would 
likely be small.

Although it is a clear bug, we decided that it was not severe enough to warrant 
a change to the bitstream. Consequently, we decided to leave the bitstream 
unchanged at this stage.

Original comment by agra...@google.com on 9 Sep 2014 at 6:26

• Changed state: Done