Decoder produces different output head vs. af7b7ffb4e on Brokenfile1.webm

[GoogleCodeExporter]

What is the expected behavior? What do you see instead?
Decoder output md5 is different at head from commit hash af7b7ffb4e

What version are you using? On what operating system?
x86_64-win64-vs11

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?
Yes, vpxdec

Please provide any additional information below.

Original issue reported on code.google.com by ya...@google.com on 13 Mar 2014 at 12:50

Attachments:

• BrokenFile1.webM

[GoogleCodeExporter]

After merging the two patches: 
https://gerrit.chromium.org/gerrit/#/c/69223/
https://gerrit.chromium.org/gerrit/#/c/69224/
that reverted two commits, head and af7bf7ffb4e still produce different md5 for 
BrokenFile1.webM using "vpxdec --md5 --i420 BrokenFile1.webM" 
Head(17256ad763): 
b57ab7e0910e98df1b8ed0790dfbd19b
af7bf7ffb4e:
bfcb008d5cc0eba82c5ed1fa70b7176b

Original comment by ya...@google.com on 13 Mar 2014 at 3:31

[GoogleCodeExporter]

"6c9dcae" is the first commit that produces b57ab7e0910e98df1b8ed0790dfbd19b.

Original comment by ya...@google.com on 13 Mar 2014 at 3:48

[GoogleCodeExporter]

proposing fix here: 
https://gerrit.chromium.org/gerrit/#/c/69249/

Original comment by ya...@google.com on 15 Mar 2014 at 12:29

[GoogleCodeExporter]

1. The width and height of the mc_buffer are miscalculated in some scale cases.

2. The topleft corner of the reference block is miscalculated due to error 
accumulation. 
    In the original reference decoder, the topleft corner is calculated as 
    sf->scale_value_x(x_start, sf) + sf->scale_value_x(x, sf);
  where sf->scale_value_x(x_start, sf) is the topleft corner of the containing block in scaled reference frame and sf->scale_value_x(x, sf) is the topleft corner of the reference block inside the containing block.
     In the code after modified, the topleft corner is calculated as 
     sf->scale_value_x(x_start + x, sf); 
   This calculation is mismatch with sf->scale_value_x(x_start, sf) + sf->scale_value_x(x, sf) in some cases. But this calculation is actually more accurate than before but it change the decoder output. So we revert it to keep the same as before. 

Original comment by hku...@google.com on 17 Mar 2014 at 6:43

[GoogleCodeExporter]

This issue was closed by revision 1f7e4856f8f5.

Original comment by hku...@google.com on 19 Mar 2014 at 6:23

• Changed state: Fixed

[GoogleCodeExporter]

The final resolution of the issue is here: 
https://gerrit.chromium.org/gerrit/#/c/69319/

The scaling calculation is finalized as in the commit to be in sync with 
hardware implementations.

Original comment by ya...@google.com on 28 Mar 2014 at 3:07