min_fs_radius, max_fs_radius, full_freq were set but never read.

Change-Id: I82657f4e7f2ba2acc3cbc3faa5ec0de5b9c6ec74

Minor fix.

Change-Id: Iaf93f6e47e882a33c479e57c7a0d0bf321e291c0

Previously allocated more memory than necessary for yuv buffers.
This makes it harder to track bugs with reading uninitialized
data.

Change-Id: I510f7b298d3c647c869be6e5d51608becc63cce9

Code has not been used and is no longer relevant.

Change-Id: I38590513da7c7a436804ff8a1a3805d9697f575d

Change-Id: I5fe581d797571a7a9432fbd17fc557591d0c1afa

Change-Id: I65105a9c63832669237e6a6a7fcb4ea3ea683346

Clamp mv search to accomodate subpixel filtering
of UV mv.

Change-Id: Iab3ed405993ef6bf779ad7cf60863153068fb7d1

Scott suggested to move vp8_mv_pred() under "case NEWMV" to save
extra checks.

Change-Id: I09e69892f34a08dd425a4d81cfcc83674e344a20

Do mvp clamping in full-pixel precision instead of 1/8-pixel
precision to avoid error caused by right shifting operation.
Also, further fixed the motion vector limit calculation in change:
b7480454

Change-Id: Ied88a4f7ddfb0476eb9f7afc6ceeddbf209fffd7

Change-Id: I1ed739522db7c00c189851c7095c1b64ef6412ce

Separate simple filter with reduced no. of parameters.
MB filter level picking based on precalculated table. Level table updated for
each frame. Inside and edge limits precalculated and updated just when
sharpness changes. HEV threshhold is constant.
ARM targets use scalars and others vectors.

Change works only with --target=generic-gnu
All other targets have to be updated!

Change-Id: I6b73aca6b525075b20129a371699b2561bd4d51c

Allow the encoder to inform the application that the encoded frame will not
be used as a reference.

Change-Id: I90e41962325ef73d44da03327deb340d6f7f4860

This should fix binaries using PIC on x86-32. Also should
fix issue 343.

Change-Id: I591de3ad68c8a8bb16054bd8f987a75b4e2bad02

Motion vector limits are calculated using right shifts, which
could give wrong results for negative numbers. James Berry's
test on one clip showed encoder produced some artifacts. This
change fixed that.

Change-Id: I035fc02280b10455b7f6eb388f7c2e33b796b018

and divide by 0 errors

Change-Id: I8af5ca3d0913cb6f278fff754f8772bcb62e674a

In this commit I have added an experimental function
that tests prediction quality either side of a central position
to calculate a suggested boost number for an ARF frame.

The function is passed an offset from the current position and
a number of frames to search forwards and backwards.
It returns a forward, backward and compound boost number.

The new code can be deactivated using #define NEW_BOOST 0

In its current default state the code searches forwards and backwards
from the proposed  position of the next alt ref.

The the old code used a boost number calculated by scanning forward
from the previous GF up to the proposed alt ref frame position.

I have also added some code to try and prevent placement of a gf/arf
where there is a brief flash.

Change-Id: I98af789a5181148659f10dd5dd2ff2d4250cd51c

Values were set, then reset. Only set them once.

Change-Id: Iaf43c8467129f2f261f04fa9188b603aa46216b5

Change-Id: I3683cb87e9cb7c36fc22c1d70f0799c7c46a21df

For clips that are near 60fps and have a lot of alt refs, it's possible
that the ring buffer holding the previous frames sizes/pts could wrap
around, leading to a division by zero.

In addition to checking for this condition in the ring buffer loop,
the buffer size is made dependent on the actual frame rate in use,
rather than defaulting to 60, which should improve accuracy at frame
rates >= ~60.

Change-Id: If5a04d6e847316dc5f7504f25c01164cf9332be8