| Age | Commit message (Collapse) | Author |
|---|
|
This patch checks that a decoder never tries to reference frame that's
outside the range of 2x to 1/16th the size of this frame. Any attempt
to do so causes a failure.
Change-Id: I5c98fa7bb95ac4f29146f29dd92b62fe96164e4c
|
|
For very large size video image, the scaling calculation may need use
value beyond the range of int. This commit upgrade the value to 64bit
to make sure the calculation do not wrap around INT_MAX.
The change corrected the decoder behavior.
The bug affects only very large resolution video because the scaling
calculation was sufficient for image size smaller than 2^13.
This resolves issue:
https://code.google.com/p/webm/issues/detail?id=750
Change-Id: I2d2ed303ca6482f31f819f3c07d6d3e98ef3adc5
|
|
Moving back to scale_factors struct. We don't need anymore x_offset_q4 and
y_offset_q4 because both values are calculated locally inside vp9_scale_mv
function.
Change-Id: I78a2122ba253c428a14558bda0e78ece738d2b5b
|
|
The ref's scale_factors are set at frame level, and then copied for
each partition block. Since the struct members are mostly constant,
this patch separated the constant and non-constant members, and
reduced struct copying. This gave 0.5% ~ 1.4% decoder speed gain.
Change-Id: I94043bf5a6995c8042da52e5c661818dfa6f6d4c
|
|
Change-Id: I481d9bb2fa3ec72b6a83d5f04d545ad8013f295c
|
|
It is possible to have invalid scale factors and not access them
during decoding. Error is reported if we really try to use invalid scale
factors.
Change-Id: Ie532d3ea7325ee0c7a6ada08269f804350c80fdf
|
|
We support only [1/16, 2] scale factors, enforcing this now.
Change-Id: I0822eb7cea51720df6814e42d3f35ff340963061
|
|
Reusing existing functions, using constants instead of magic numbers.
Change-Id: Idc689ffba52c9a8b203fcf26bd67110ecb5635f9
|
|
Change-Id: I531829e5aee2a4a7a112d528ecccbddf052d0e74
|
