| Age | Commit message (Collapse) | Author |
|---|
|
Enable entropy coding of motion vectors up to +/-2048. Also
extend the motion search range accordingly.
Change-Id: Iac2bb015e8934521cef83a19edbe967d9f097436
|
|
|
|
Remove the temporary branch count arrays and build the adapted probabilities
while walking the tree. Gives an additional 1.5% or so on CIF.
Change-Id: I875d61e5e0ec778e5d2f7f9d0837b989a91cf3a3
|
|
|
|
|
|
Adds a check to exit from the increment_nmv_count function when the
increment is 0.
Change-Id: I99c1e342d351f7800e23590f9c2419881bf1d708
|
|
The previous implementation visited each node in the tree multiple times
because it used each symbol's encoding to revisit the branches taken and
increment its count. Instead, we can traverse the tree depth first and
calculate the probabilities and branch counts as we walk back up. The
complexity goes from somewhere between O(nlogn) and O(n^2) (depending on
how balanced the tree is) to O(n).
Only tested one clip (256kbps, CIF), saw 13% decoding perf improvement.
Note that this optimization should port trivially to VP8 as well. In VP8,
the decoder doesn't use this function, but it does routinely show up
on the profile for realtime encoding.
Change-Id: I4f2848e4f41dc9a7694f73f3e75034bce08d1b12
|
|
Increase the motion search range by 4x. Change MV_CLASS tree of the
entropy coding to allow two additional mv classes to cover the
extended motion vector limit. The codec determines the effective
motion search range conditioned on the actual frame dimension.
It provides coding gains:
stdhd 0.39%
yt 0.56%
hd 0.47%
Major coding performance gains are packed in several sequences with
intense motion activities, e.g., ped_1080p gains 7% at high bit-rates,
and on average 3%.
TODO: Need to further tune the rate control and motion search units.
Change-Id: Ib842540a6796fbee5a797809433ef6a477c6d78d
|
|
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
|
|
Change-Id: Ia1cce221f8511561b9cbd8edb7726fbc286ff243
|
|
Support for gyp which doesn't support multiple objects in the same
static library having the same basename.
Change-Id: Ib947eefbaf68f8b177a796d23f875ccdfa6bc9dc
|
