search

dinhminhquoi / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

WRITE_COEF_CONTINUE has bug in 32bit to 16bit conversion #792

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What is the expected behavior? What do you see instead?

In vp9_detokenize.c, the WRITE_COEF_CONTINUE macro has bug in 32bit to 16bit 
conversion. deqcoeff[scan[c]] should be CLIP to [-32768, 32767], instead of 
implicitly conversion.

dqcoeff[scan[c]] = clamp(vp9_read_bit(r) ? -v : v, -32768, 32767)  \

instead of:

 #define WRITE_COEF_CONTINUE(val, token)                  \
  {                                                      \
    v = (val * dqv) >> dq_shift;                         \
    dqcoeff[scan[c]] = vp9_read_bit(r) ? -v : v;         \
    token_cache[scan[c]] = vp9_pt_energy_class[token];   \
    ++c;                                                 \
    ctx = get_coef_context(nb, token_cache, c);          \
    dqv = dq[1];                                         \
    continue;                                            \
  }

What version are you using? On what operating system?

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

Yes, using vpxdec.

Please provide any additional information below.

Original issue reported on code.google.com by y...@avsx.org on 26 May 2014 at 6:28

GoogleCodeExporter commented 8 years ago 
More details are given as follows:

A quantized coefficient val in bitstream is 0x000004dc  ( 1244 ),  after 
quantized (dqv=48 and dq_shift=0), v will be 0x0000e940 ( 59712 ). But dqcoeff 
is 16 bits and it should be clipped to [-32768, 32767], so the dqcoeff should 
be 32767 (0x7FFF).

But VP9 reference software forget to clip it, it just use: dqcoeff[scan[c]] = 
vp9_read_bit(r) ? -v : v; , where v is 32 bit (0x0000e940) and dqcoeff is 
16bit. So, dqcoeff  became -5824 (0xe940).

Original comment by y...@avsx.org on 27 May 2014 at 12:36

GoogleCodeExporter commented 8 years ago 
The dequantized coefficients here are expected to be always within the range 
[-32768, 32767], therefore no clamping is necessary. 

Can you provide details on how this coefficient was produced? i.e. 
configure/build/encoding parameters and input video clips. So we can 
investigate further.

Original comment by ya...@google.com on 30 May 2014 at 2:14

GoogleCodeExporter commented 8 years ago 
Please check the decoding for the attached bitstream.
We can see the below assertion failure.
INT16_MIN<= rv && rv <= INT16_MAX

Original comment by holy...@gmail.com on 30 May 2014 at 5:58

Attachments:

GoogleCodeExporter commented 8 years ago 
In q64_dqc_issued.webm, Frame 2 (0,1,2...), SB position (320, 64) and the 
second 16x16 Transfrom block has the above mentioned issue.

Original comment by y...@avsx.org on 30 May 2014 at 10:13

GoogleCodeExporter commented 8 years ago 
For bit depth at 8, the input video pixel values range from 0 to 255, it is not 
possible for 16x16 transform to produce a coefficient at 59712. Most likely, 
the stream is an ill-formed stream. 

For better detection, we propose the following CL:
https://gerrit.chromium.org/gerrit/#/c/71753/

Original comment by ya...@google.com on 7 Oct 2014 at 6:27

GoogleCodeExporter commented 8 years ago

Original comment by ya...@google.com on 7 Oct 2014 at 6:58

GoogleCodeExporter commented 8 years ago 
https://gerrit.chromium.org/gerrit/#/c/71753/ is now merged.

Original comment by ya...@google.com on 7 Oct 2014 at 7:37

GoogleCodeExporter commented 8 years ago 
https://gerrit.chromium.org/gerrit/#/c/71753/ is now merged.

Original comment by ya...@google.com on 7 Oct 2014 at 7:37