| 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
|
|
The encoder currently allocates frame buffers before
it establishes what the chroma sub-sampling factor is,
always allocating based on the 4:4:4 format.
This patch detects the chroma format as early as
possible allowing the encoder to allocate buffers of
the correct size.
Future patches will change the encoder to allocate
frame buffers on demand to further reduce the memory
profile of the encoder and rationalize the buffer
management in the encoder and decoder.
Change-Id: Ifd41dd96e67d0011719ba40fada0bae74f3a0d57
|
|
Change-Id: Ic4fc01be7738fbabf8c7860dbe3476ab4caf5fc2
|
|
Change-Id: Ic334da9aee968e33762c2b25d9fbad24c844b411
|
|
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: Ia7969baac7ffc6d7a0e8e8e83e9252d077a3c5b3
|
|
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
|
|
Change-Id: Ieb7077ca3586b9491912027eed450a4f6fd38d30
|
|
We support only [1/16, 2] scale factors, enforcing this now.
Change-Id: I0822eb7cea51720df6814e42d3f35ff340963061
|
|
Change-Id: I531829e5aee2a4a7a112d528ecccbddf052d0e74
|
