VP9/DatarateTestVP9Large.ChangingDropFrameThresh/[34] fails post the
merge of commit#ffa06b37. This commit adds reset of rc tracking info
when frame is dropped, and fixes the causes of the bad interaction
between the tests and the previous commit.

Change-Id: I848acfd9fcb336359662274325190f94aac76eae

This commit reworks the forward transform and quantization process
for 8x8 block coding. It combines the two operations in a single
function to save a store/load stage of the original transform
coefficients. Overall the speed -6 is slightly faster (around 1%
range). The compression performance of speed -6 is improved by
3.4%.

Change-Id: Id6628daef123f3e4649248735ec2ad7423629387

Fixes a borg build.

Change-Id: I8cb510577e8d8bbc7a2e64f9e1bdfe883f49cb61

In rare cases, the interaction between rate correction factor and Q
choices may cause severe oscillating frame sizes that are way off
target bandwidth. This commit adds tracking of rate control results
for last two frames, and use the information to prevent oscillating
Q choices.

Change-Id: I9a6d125a15652b9bcac0e1fec6d7a1aedc4ed97e

vp9_quantize_fp is the quantization process used by rtc coding
mode. This commit adds a sse2 implementation of it. The
implementation is modified based on vp9_quantize_b_sse2. No speed
difference from ssse3 version.

Change-Id: I24949c5b27df160b4f35117d28858d269454e64a

Current setting had active_worst_quality set too high (close to worst_quality)
for first frame(s) following first key frame. This changes that to be somewhat
more aggressive in allowing active_worst_quality to be lower following key frame.

Also remove the 4/5 reduction in active_worst for key frame as
this should be set by the user qp_max setting.

Change-Id: I0530b3ddcc85c00e3eb7568de1b14a31206c4a4c

The function pointer in compressor instance does not change, so this
commit changes to call the function directly.

Change-Id: I9c9c460e3475711c384b74c9842f0b4f3d037cc5

This commit adds a check condition to the prediction buffering
operation used in the rtc coding mode. This resolves a unit test
warning in example/vpx_tsvc_encoder_vp9_mode_7.

Change-Id: I9fd50d5956948b73b53bd8fc5a16ee66aff61995

These 2 members in RD_OPT were moved to TileDataEnc struct
already, and therefore were removed here.

Change-Id: I22fee3b67f96e473a58e194a7edc76dbd48bfa04

Several frame counters in encoder are updated at SB level. Combine
those counters and put them in a separate struct, which allows us
to allocate one copy for each thread.

Change-Id: I00366296a13c0ada4d8fa12f5e07728388b6cab7

Change-Id: I446bdf3a405e4e9d2aa633d6281d66ea0cdfd79f
(cherry picked from commit d7422b2b1eb9f0011a8c379c2be680d6892b16bc)
(cherry picked from commit 6d741e4d76a7d9ece69ca117d1d9e2f9ee48ef8c)

Change-Id: If74510370723e497f4f33d988b8b398124edf69b

Modified VP9_COMP struct to include MACROBLOCK *mb. This change
makes it feasible in multi-thread case to allocate a mb for each
thread.

Change-Id: I624d6d1aa9c132362200753e5d90b581b1738d6e

Average and variance of actual encoding bitrate over fixed short-time window.

Change-Id: Icc3d6d93792c81e1fb9fd3b56008bf47a503b204

Two members in struct CYCLIC_REFRESH
  int64_t projected_rate_sb;
  int64_t projected_dist_sb;
are updated at the superblock level, which makes them shared data
in the multi-thread situation, and requires extra work to handle
them. However, those values are updated and used immediately, and
therefore can be removed. This patch cleaned up the code and
removed the two members.

Change-Id: I2c6ee4552bf49fb63ce590cdb47f9723974fffb1

Prepare for the introduction of frame-size change
logic into the recode loop.

Separated the speed dependent features into
separate static and dynamic parts, the latter being
those features that are dependent on the frame size.

Change-Id: Ia693e28c5cf069a1a7bf12e49ecf83e440e1d313

Add extra vp9_clear_system_state() calls to fix
double / mmx issue introduced into first pass
code for 32 bit builds.

Change-Id: I84cd2986b80d83650a091ab25c43755efeb82e03

This reverts commit 7d07f512.

this breaks visual studio builds:
'#' : invalid character : possibly the result of a macro expansion

Change-Id: I77170d549afb71e75a878fa0f6acd204fe8d9e67

Rate correction factor is used to correct the estimated rate for any
given quantizer, and feeds into rate control for quantizer selection.
We make use of the actual bits used to calculate this rate correction
factor with an adjustment limit to prevent over-adjustment.

This commit adapts the adjustment limit to the difference between the
estimated bits and the actual bits, allows the adjustment limit to vary
between 0.125 (when estimate is close to actual) and 0.625 (when there
is >10X factor off between estimated and actual bits). By doing this,
the commit appears to have largely corrected two observed issues:
1. Adjustment is too slow when the actual bits used is way off from
estimate due to the small adjustment limit.
2. Extreme oscillating quantizer choices due to the feedback loop.

Change-Id: I4ee148d2c9d26d173b6c48011313ddb07ce2d7d6