Modify the second-pass code to provide a full golden-frame (GF) bit
allocation boost if the past GF group (GFG) had no alt-ref frame (ARF),
even if the current GFG does contain and ARF.

This mostly has no effect on clips, since switching ARFs on/off between
GFGs is not very common. Has a positive effect on e.g. cheer (+0.45 SSIM
at 600kbps) and football (+0.25 SSIM at 600kbps), particularly at high
bitrates. Has a negative effect (-0.04 SSIM at 300kbps) at pamphlet,
which appears only marginally related to this patch, and crew (-0.1 SSIM
at 700kbps).

Change-Id: I2e32899638b59f857e26efeac18a82e0c0b77089

The BPRED mode selection uses SSE as a distortion metric, but the early
breakout threshold being used was a variance value.

Change-Id: I42d4602fb9b548bf681a36445701fada5e73aff1

firstpass.c contains some rate adjustment code that assures that the
last few frames in a sequence abide by rate limits. If the second-to-
last group of frames contains an alt-ref frame (ARF), the last golden
frame (GF) is zero bytes, and we will thus spend a ridiculously high
number of bits on regular P-frames trying to hit the target rate. This
does slightly enhance the quality of these last few frames, but has
no perceptual value (other than hitting the target rate).

Disabling this code means we consistently (slightly) undershoot the
target rate and consequently do worse on the last few frames of a
clip, which is particularly noticeable for small clips. The quality-
per-bitrate is generally better, ~0.2% better overall on derf-set,
especially on clips such as garden, tennis, foreman at low bitrates.
Has a negative effect on hallmonitor at high bitrates.

Change-Id: I1d63452fef5fee4a0ad2fb2e9af4c9f2e0d86d23

Change-Id: Ib8e429152c9a8b6032be22b5faac802aa8224caa

Moved encode_intra function from firstpass.c to encodeintra.c to
prevent linking problem in real-time only build. Also changed name
of the function to vp8_encode_intra because it is not a static.

Change-Id: Ibf3c6c1de3152567347e5fbef47d1d39564620a5

Small decode performance gain (~1%) on keyframes.  No
noticeable gains on encode.  Also changed pick_intra4x4mby_modes()
to read the above and left block modes for keyframes only.

Change-Id: I1f4885252f5b3e9caf04d4e01e643960f910aba5

instead of every macro block.

Change-Id: I2604e94c6b89e3a8457777e21c8c38406d55b165

call to this set of functions are replaced by var16x16.

Change-Id: I5ff1effc6c1358ea06cda1517b88ec28ef551b0d

uninitialized xd->mode_info_context would crash
vpxenc for --error-resilient=1.

Change-Id: I31849e40281e3d65ab63257cfec5e93398997f0b

Activity update is no longer dependent on being in RD mode, so update
it unconditionally.

Change-Id: Ib617a6fc210dfc045455e3e4467d7ee5e3d1fa0e

Better fix for #326. ICC happens to support the inline magic

Change-Id: Ic367eea608c88d89475cb7b05d73500d2a1bc42b

Since BPRED will be tested at most once, and SPLITMV is not enabled,
there's nothing to clobber the subblock modes, so there's no need to
save and restore them.

Change-Id: I7c3615b69190c10bd068a44df5488d6e8b85a364

The returned rate was always the 4x4 rate, instead of the rate
matching the selected mode.

Change-Id: I51da31f80884f5e37f3bcc77d1047d31e612ded4

Change-Id: Ib641c624faec28ad9eb99e2b5de51ae74bbcb2a2

In activity masking, RDO constant RDMULT is adjusted on a per MB basis
adaptive to activity with the MB. errorperbit, which is defined as
RDMULT/RDDIV, is a constant used in motion estimation. Previously, in
activity masking, errorperbit is not changed even when RDMULT is changed.
This commit changed to adjust errorperbit according to the change in
RDMULT.

Test in cif set showed a very small but consistent gain by all quality
metrics (average, overall psnr and ssim) when activity masking is on.

Change-Id: I07ded3e852919ab76757691939fe435328273823

This change is analogous to I0b67dae1f8a74902378da7bdf565e39ab832dda7,
which made the move for the non-RD path.

Change-Id: If63fc1b0cd1eb7f932e710f83ff24d91454f8ed1

This commit moves the intra block mode selection from encodeframe.c
to pickinter.c (in the non-RD case). This allowed pick_intra_mbuv_mode
and pick_intra4x4mby_modes to be made static, and is a step towards
refactoring intra mode selection in the main pickinter loop. Gave a
small perf increase (~0.5%).

Change-Id: I0b67dae1f8a74902378da7bdf565e39ab832dda7

Some further re-structuring of activity masking code.
Still has various experimental switches.
Supports a metric based on intra encode.
Experimental comparison against a fixed activity target  rather
than a frame average, for altering rd and zbin.

Overall the SSIM performance is similar  to TT's original
code but there is a much smaller PSNR hit of circa
0.5% instead of 3.2%

Change-Id: I0fd53b2dfb60620b3f74d7415e0b81c1ac58c39a

While investigating the effect of DC values on SAD and SSE in motion
estimation, a side finding indicates the two table of constants need
be adjusted. The adjustment was done by multiplying old constants by
90% with rounding. Also absorb the 1/2 scaling constant into the two
tables. Refer to change Ifa285c3e for background of the 1/2 factor.

Cif set test showed a very small gain on all metric.

Change-Id: I04333527a823371175dd46cb04a817e5b9a8b752

Change-Id: I5b0aaca06f2e0f40588cb24fb0642b6865da8970

The encoder defined about 4 set of similar functions to calculate sum,
variance or sse or a combination of them. This commit removed one set
of these functions, get8x8var and get16x16var, where calls to the later
function are replaced with var16x16 by using the fact on a 16x16 MB:
    variance == sse - sum*sum/256

Change-Id: I803eabd1fb3ab177780a40338cbd596dffaed267

In real-time mode motion search, there is no need to calculate
variance. This change improved encoding speed by 1% ~ 2%(speed=-5).

Change-Id: I65b874901eb599ac38fe8cf9cad898c14138d431

This patch attempts to reduce the peak bitrate hit by the encoder
when using small buffer windows.

Tested on the CIF set over 200-500kbps using these settings:

  --buf-sz=500 --buf-initial-sz=250 --buf-optimal-sz=250 \
  --undershoot-pct=100

Two pass encodes were tested at best quality. One pass encodes were
tested only at realtime speed 4:

  --rt --cpu-used=-4

The peak datarate (over the specified 500ms window) was measured
for each encode, and averaged together to get metric for
"average peak," computed as SUM(peak)/SUM(target). This patch
reduces the average peak datarate as follows:

  One pass:
    baseline:   1.29715
    this patch: 1.23664

  Two pass:
    baseline:   1.32702
    this patch: 1.37824

This change had a positive effect on our quality metrics as well:

  One pass CBR:
                    Min  / Mean / Max (pct)
    Average PSNR    -0.42 / 2.86 / 27.32
    Overall PSNR    -0.90 / 2.00 / 17.27
    SSIM            -0.05 / 3.95 / 37.46

  Two pass CBR:
                    Min  / Mean / Max (pct)
    Average PSNR    -4.47 / 4.35 / 35.99
    Overall PSNR    -3.40 / 4.18 / 36.46
    SSIM            -4.56 / 6.98 / 53.67

  One pass VBR:
                    Min  / Mean / Max (pct)
    Average PSNR    -5.21 /  0.01 / 3.30
    Overall PSNR    -8.10 / -0.38 / 1.21
    SSIM            -7.38 / -0.11 / 3.17
    (note: most values here were close to the mean, there were a few
     outliers on files that were very sensitive to golden frame size)

  Two pass VBR:
                    Min  / Mean / Max (pct)
    Average PSNR    0.00 / 0.00 / 0.00
    Overall PSNR    0.00 / 0.00 / 0.00
    SSIM            0.00 / 0.00 / 0.00

Neither one pass or two pass CBR mode adheres particularly strictly
to the short term buffer constraints, and two pass is less
consistent, even in the baseline commit. This should be addressed
in a later commit. This likely will hurt the quality numbers, as it
will have to reduce the burstiness of golden frames.

Aside: My work on this commit makes it clear that we need to make
rate control modes "pluggable", where you can easily write a new
one or work on one in isolation.

Change-Id: I1ea9a48f2beedd59891f1288aabf7064956b4716

Currently, hex search couldn't guarantee the motion vector(MV)
found is within the limit of maximum MV. Therefore, very large
motion vectors resulted from big motion in the video could cause
encoding artifacts. This change adjusted hex search bounds
checking to make sure the resulted motion vector won't go out
of the range. James Berry, thank you for finding the bug.

Change-Id: If2c55edd9019e72444ad9b4b8688969eef610c55

Declared the bmi in BLOCKD as a union instead of B_MODE_INFO.
Then removed B_MODE_INFO completely.

Change-Id: Ieb7469899e265892c66f7aeac87b7f2bf38e7a67

This is basically a slightly modified version of the previous patch,
and it has a moderately positive effect (SSIM/PSNR both +0.08% avg
on derf-set). Most clips show no change, except waterfall/coastguard,
each ~ +0.8% SSIM/PSNR. You can see similar effects in other clips
by shortening their length to terminate at a very short last group
of frames.

Change-Id: I7a70de99ca1f9fe6a8b6ca7a6e30e8a4b64383e4

this commit makes the usage errorperbit and sadperbit consistent for
encoding modes and passes. Removed all different magic weight factors
associated with errorperbit. Now 1/2 is used for both sadperbit16 and
sadperbit4, the /2 operation is merged into initializations of the 2
variables.

Tests on cif set show .23%, 0.18% and 0.19% gain by avg psnr, overall
psnr and ssim respectively.

Change-Id: Ifa285c3e065ce0a5a77addfc9f95aabf54ee270d

Change-Id: Iccbd78d91c3071b16fb3b2911523a22092652ecd

sad_per_bit has been used for a number of motion vector search routines
with different magic weights: 1, 1/2 and 1/4. This commit remove these
magic numbers and use 1/2 for all motion search routines, also reformat
a number of source code lines to within 80 column limit.

Test on cif set shows overall effect is neutral on all metrics. <=0.01%

Change-Id: I8a382821fa4cffc9c0acf8e8431435a03df74885

vp8_fast_quantize_b_pair_neon function added to quantize
two adjacent blocks at the same time to improve performance.
 - Additional 3-6% speedup compared to neon optimized fast
   quantizer (Tanya VGA@30fps, 1Mbps stream, cpu-used=-5..-16)

Change-Id: I3fcbf141e5d05e9118c38ca37310458afbabaa4e

Small code cleanups before attempting to reduce the size
of bmi found in BLOCKD.

Change-Id: Ie9c14adb53afd847716a75bcce067d0e6c04f225

Misplaced #endif caused first_time_stamp_ever to only be initialized if
CONFIG_INTERNAL_STATS was set.

Change-Id: I2296a4ab00f7dfb767583edcc5d59b94f48c0621

Added preload instructions to armv6 encoder optimizations.
About 5% average speed-up on Tegra2 for VGA@30fps sequence.

Change-Id: I41d74737720fb71ce7a316f07555357822f3347e

in onyx_if.c update_reference_frames() make
sure that frame buffer indexes are not equal
before preforming a buffer copy.  If two frames
share the same buffer the flags will already be
set correctly.

Change-Id: Ida9b5516d08e3435c90f131d2dc19d842cfb536e

Test showed using hex search in realtime mode largely speed up
encoding process, and still achieves similar quality like the
diamond search we have. Therefore, removed the diamond search
option.

Change-Id: I975767d0ec0539f9f6ed7fdfc09506e39761b66c

Hex search is not called in rdopt.c

Change-Id: I67347f03e13684147a7c77fb9e9147e440bb5e8e

error_per_bit and sad_per_bit were designed as estimates of a bit worth
of sum squared error and sum absolute difference respectively. Under
this assumption, error_per_bit should be used in combination with 2nd
order errors (variance or sum squared error) while sad_per_bit should
be used in combination with 1st order SADs in motion estimation. There
were a few places where sad_per_bit has been misused with variances,
this commit changes to use error_per_bit for those places, also changes
parameter names to properly indicate which constant is being used.

On cif set, the change has a universal gain by all metrics: 0.13% by
average/overall psnr and 0.1% by ssim.

Change-Id: I4850fdcc3fd6886b30f784bd843f13dd401215fb

Change-Id: I6e5e86235d341cce3b02abda26dbeb71940ed955

Minor modification.

Change-Id: I09511d38fd1451d5c4106a48acdb3f766ce59cb7

  'sum' returned by get8x8var is not used and var8x8 has optimizations
  for more platforms.

Change-Id: I4a907fb1a05f285669fb0b95dc71d42182c980f6