See issue 1051. 6 bits is fairly arbitrary but at least allows writing
delta Q values that are fairly normal in other codecs. I can extend to
8 if people want full range, although I personally don't have any need
for that.

Change-Id: I0a5a7c3d9b8eb3de4418430ab0e925d4a08cd7a0

See issue 1079.

Change-Id: I754a61ec011c3508bbb26826cf8e11dbdfdd8379

Dynamic resizing now support two-steps scaling: first go down to
3/4 and then 1/2. This feature is under a flag which controls the
switch between two-steps scaling and one-step scaling (1/2 only).

Change-Id: I3a6c1d3d5668cf8e016a0a02aeca737565604a0f

Change-Id: I5aeaa94b743f84738d288f8b027fec4c164f2ec3

This is more a proof of concept than anything else. The problem here
isn't so much how to code it, but rather where to place the resulting
code. All intrapred DSP code lives in vpx_dsp, so do we want the vp10
specific intra pred functions to live there, or in vp10/?

See issue 1015.

Change-Id: I675f7badcc8e18fd99a9553910ecf3ddf81f0a05

The x86 simd expects this. Identical alignment can be found in vp9
and vp10 also. Fixes crashes on 32bit x86 systems.

Change-Id: I229c88d8f696acbef5337c8fa9503528df4e1c40

I've added a few new functions (d45e, d63e, he, ve) to cover the
filtered h/v 4x4 predictors that are vp8-specific, the "correct"
d45 with the correctly filtered bottom-right pixel (as opposed to
the unfiltered version in vp9), and the "broken" d63 with weirdly
filtered bottom-right pixels (which is correctly filtered in vp9).

There may be a minor performance impact on all systems because we
have to do an extra copy of the Above pixel array to incorporate
the topleft pixel in the same array (thus fitting the vpx_dsp API).
In addition, armv6 will have a more serious performance impact b/c
I removed the armv6/vp8-specific assembly. I'm not sure anyone
cares...

Change-Id: I7f9e5ebee11d8e21aca2cd517a69eefc181b2e86

Change-Id: I936c2430c3c5b1e0ab5dec0a20110525e925b5e4

Change-Id: I2000820e0c04de2c975d370a0cf7145330289bb2

Change-Id: Ia5072a3a92212d8565f33359f6c146469bdfbbec

* changes:
  vp9_loopfilter: remove unnecessary masks
  vp9_reset_lfm: harmonize function signature

* changes:
  vp9_thread_test: clarify test case names
  vp9_thread_test: add non-frame-parallel files

Change-Id: I264e75bf3ddd083ee5311c50a37fb18fe634ddc3

define NOMINMAX to allow the std:: versions to be used; min/max will be
defined transitively via windows.h otherwise

Change-Id: I692b03fa3e70b7a53962d3fd209498f70f712fed

Change-Id: Ifb0f41fb43564a777be29b4c66443b366fa146a3

Change-Id: Iad73b490b171cdda5c368ada69fb8eab2a86c156

vp9_filter_block_plane_ss11() and vp9_filter_block_plane_non420()
are only called for the uv planes.

Change-Id: Iacd3b3242c8ce581edd37c8f06d95efc8a0f88a3

BUG=https://code.google.com/p/webm/issues/detail?id=1066

Change-Id: I3bd26a516ef3d2742c523af570f639f9312df6df

Change-Id: I63fadf1c7240d4b2893384f75c519311e9659d47

to be consistent with the head file name.

Change-Id: I9634332a2b3fac7e7f3b7ef58821ea7c81c5c813

The loopfilter masks are now built in the decode loop.
This is done so we can eventually reduce the number of
MODE_INFO structs required by the decoder.

The encoder builds the masks for the entire frame prior
to calling the loopfilter.

Change-Id: Ia2146b07e0acb8c50203e586dfae0c4c5b316f11

When configured with high bitdepth enabled, the 8bit transform
stopped using optimised code. This made 8bit content decode slowly.

Change-Id: I67d91f9b212921d5320f949fc0a0d3f32f90c0ea

Update rate correction factor when we drop the frame due to overshoot.
Only affects when the drop_overshoot feature is on: screen_content_mode = 2.

Change-Id: I67e24de979b4c74744151d2ceb3cd75fec2a1e7a