This patch allows the encoder to skip the search for partition
SPLIT, HORZ, VERT after the search for partition NONE is done
in RD optimization. It uses the first pass block-wise statistics
to make the decision. If all 16x16 blocks in the current partition
have zero motions and small residues from the frist pass statistics,
and it has small difference variance, further partition search is
skipped.

For speed 2 setting, experiments on general youtube clips show that
the speedup varies from 1% - 10%, 5% on average. On the performance
side in PSNR, derf 0.004%, yt -0.059%, hd -0.106%, stdhd 0.032%.

For hard stdhd clips:
park_joy_1080p, 502952 ms -> 503307 ms (-0.07%)
pedestrian_area_1080p, 227049 ms -> 220531 ms (+3%)

This feature is under the compilation flag CONFIG_FP_MB_STATS and
it is off in current setting.

Change-Id: I554537e9242178263b65ebe14a04f9c221b58bae

Change-Id: Ie4686e1b15af6bcc8d59d585bbeb996f38224522

On a Nexus 7, vpxenc (in realtime mode, speed -12)
reported a performance improvement of ~3.7%.

Change-Id: I428c72c40df82c6d537955e320a8debf99343004

Remove the redundant index computation when store the first
pass block-wise statistics. Currently, a single byte is
allocated for a 16x16 blocks, and all the frame statistics
saved during the first pass will be kept in memory for use
in the second pass. For a 1920x1080 300-frame clip, it will
take about 2.3 MB memory. This feature is off in current
setting.

Change-Id: I135a95b348ec093d54c6a07e1e8237626909e3bd

levytamar82 authored Jul 24, 2014 and James Zern committed Jul 28, 2014

Remove all the redundant dct functions (dct4x4, dct8x8)
in avx2 except dct32x32 those functions were copied originally from dct_sse2

Change-Id: I742576fbf5175f3ac09f2076976a9247b259323e

Change-Id: I9956db2ba2f7d28f484daaf5022d8d1ef5db473c

The issue was introduced by commit g9f37d149 with adding explicit
restrictions on reference-frame scale factors. The restriction
is checked against aligned-by-8 frame dimensions, not against
original ones. So, for example, frame of 35×35 actually can refer
to frame of 70×70, but the new check won't allow this. It will
compare 35 vs 72 (not 70), so 2x downscale limit will be exceeded.

Change-Id: Ic663693034440f64ac8312cbff9e1e773a921060

Change-Id: I61993946fe5cbcd7ebeb6302efd9538bff022e5a

The partition search for 4x4 blocks takes unnecessary steps to
reconstruct pixels and an extra partition type update. This commit
removes such operations. No visible compression/speed difference.
Thanks to Yue (yuec@) for finding this issue.

Change-Id: I3f83824aa3fd3717d63be0b280fa57258939a70a

The code fails the unit test. Speed comparisons to the C are invalid
because the code frequently didn't correctly extend the right and
bottom portions of the frame.

Reduce maximum frame size on ARM devices to avoid OOM

Change-Id: Ia664c86406f0bb8120fd7ad401f32d0bd44994fb

Change-Id: I5bfc965019815e631a2300eb29aa065fb2bc94aa

The source buffer is an aligned buffer in VP9. Added the alignment
to make it consistent with libvpx.

Change-Id: I3ebb9d2e8555ed532951da479dd5cbbb8812e02d

Change-Id: Ib39cc0218a1f232c0cde8e99ca3319c17274bd48

This commit turns on the existing vp9_get_prob function using
64 bit in the intermediate step. It fixes the ioc issue for 4K
above frame sizes (issue 828).

Change-Id: I9f627f3beca2c522f73b38fd2a3e7eefdff01a7c

The assignment of the variable mode_excluded in
vp9_rd_pick_inter_mode_sub8x8 takes redundant conditional jump.
This commit removes it.

Change-Id: Ie195fbe6e54ec2ade7093d562c456a2e93143704

Ensure consistent border extension by rounding uv_crop_* at image
creation time. Where it was rounded problems could arise with the right
and bottom extensions.
When padding = 32, y_width = 64, and y_crop_width = 63:
 (padding + width - crop_width + 1) / 2
 32 + 64 - 63 + 1 should equal 32 *but*
 32 + 1 + 1 equals 34 giving a right buffer of 17 instead of 16.
By calculating uv_crop_* earlier we round up at the appropriate time and
for the same values:
 (y_crop_width + 1) / 2
 63 + 1 / 2
 64
 (padding / 2) + uv_width - uv_crop_width
 16 + 16 - 16
 16

Change-Id: If866cd1b63444771440edb1432280ac83875969b

A previous change, https://gerrit.chromium.org/gerrit/#/c/70632,
introduced a size validation for reference frames to insuare the
input stream is a valid VP9 stream. However, the logic requiring
all reference frames have valid size turned out to be too strict.

In this commit, we modify the validation to require one of the
reference frame has valid dimension. In addition, the decoder
reports error whenever it detects the use of reference frame
with invalid scalig ratio.

Change-Id: If8efc312244087556cfe00f1fcbdff811268ebad

'auto_help' was added to Getopt::Long in 2.33
this isn't strictly necessary as an unrecognized option (--help) will
issue a warning and then print the usage

Change-Id: Ia757553a4e19d22a8eb70768a8866ab1a76a0eec

The patch:
https://gerrit.chromium.org/gerrit/#/c/70814/
changed the test that determined whether the context
frame buffers needed to be reallocated or not.

The code checked for a change in total frame area
to signal the need to reallocate context buffers.
However, the above_context buffer needs to be
resized i:xf only the width of the frame has increased.

Change-Id: Ib89d75651af252908144cf662578d84f16cf30e6

This should prevent confusion with the VP8 CONFIG_TEMPORAL_DENOISING and other
flags.

Change-Id: I1fe4e2977895b7966841d861ab74317ad875b6c8

Move txfm_rd_in_plane into choose_tx_size_from_rd and cleanup callers.

Change-Id: I1df2d7dc984802bd5e204cbe881ada0d75fbb3f7

Change-Id: I5978921ab1ccad6648a5bde6ad023c3e3430f5f4