vs8
 - pull yasm.rules [1] into the source tree to avoid need to install
   file into VC/VCProjectDefaults
 - reference same w/ToolFile & RelativePath
 - update arm branch to match

vs7:
 - quote source file paths passed to yasm

[1]:
http://www.tortall.net/svn/yasm/trunk/yasm/Mkfiles/vc9/yasm.rules@2271

Change-Id: I52b801496340cd7b1d0023d12afbc04624ecefc3

Change-Id: I7b35f4717cdd204224112f72471b551617262417

Change-Id: I2a97f08cc3c7808ce5be39e910cc5147ecf03a1d

Added sse2 version of vp8_regular_quantize_b which improved encode
performance(for the clip used) by ~10% for 32 bit builds and ~3% for
64 bit builds.

Also updated SHADOW_ARGS_TO_STACK to allow for more than 9 arguments.

Change-Id: I62f78eabc8040b39f3ffdf21be175811e96b39af

Change-Id: Ib82de60cf32cf08844c3e2d88d7c587396f3892c

The RSA Data Security, Inc. implementation license bears a requirement
similar to the old problematic BSD license with advertising clause.

Change-Id: I877b71ff0548934b1c4fd87245696f53dedbdf26

Commit 3245d463 "ivfenc: support reading/writing from a pipe" broke
support for two pass encodes of raw files when done in two
invocations of ivfenc. The raw image was only set up on pass 0,
which was never hit when running with --pass=2 --passes=2.

Change-Id: I6a9858be1a8998d5bd45331123b46b1baa05b379

This patch addresses issue #79, which is a regression since commit
28de670c "Fix RD bug." If the coded error value is zero, the iiratio
calculation effectively multiplies by 1000000 by the
DOUBLE_DIVIDE_CHECK macro. This can result in a value larger than
INT_MAX, giving a negative ratio. Since the error values are
conceptually unsigned (though they're stored in a double) this patch
makes the iiratio values unsigned, which allows the clamping to work
as expected.

Use - for the filename to use stdin/stdout. Update to avoid opening
the file multiple times.

Change-Id: I356356fa16bb334d4b22abc531dc03c0d95917a3

Typo caused C version of 16x16x4 SAD to be called when built with
--disable-runtime-cpu-detect.

Change-Id: I0fe6fa67280b3a5f13acb3c8ed914f039aaaf316

ssim.c comiles in a huge (512M) amount of global scratch space. Allocating
this data on the heap would be a better solution, but this file doesn't
need to be built at all in most cases, so as a first pass, disable it
except when doing opsnr.stt output (--enable-psnr).

Change-Id: I320d812f6d652a12516a16b52295ebff20b5bd42

Thanks to James Cloos <cloos at jhcloos dot com> for the tip.

Change-Id: If377cc084dd7c16a4f51191a2aa0d83e7117ebec

XMM6 to XMM15 are non-volatile on Windows x64 ABI.  We have to save
these registers.

Change-Id: I4676309f1350af25c8a35f0c81b1f0499ab99076

(Thanks to Ronald S. Bultje)

 low and high Q ends.

Change-Id: I841dc0b8ebb150ac998f4076c148d7bb187e4301

No good reason to be tricky here. I don't know why 'break' occurred to me
as the natrual replacement for the 'return', but an if/else block is
definitely clearer.

Change-Id: I08a336307afeb0dc7efa494b37398f239f66c2cf

The new scheme introduced in I68d35a2f did not clamp chroma MVs in the SPLITMV
 case, and clamped them incorrectly (to the luma plane bounds) in every other
 case.
Because chroma MVs are computed from the luma MVs before clamping occurs, they
 could still point outside of the frame buffer and cause crashes.
This clamping happens outside of the MV prediction loop, and so should not
 affect bitstream decoding.

Vestigial.

Change-Id: Iffa9e6d5ba5199b136d7549890101da17c11e3c3

Updated the comment in change I6bef2ab5, but missed adding the code to
the commit.

Change-Id: I14d300489b79730e3995175bfe5f9271b569abe3

Restructure vp8_sixtap_predict functions to eliminate extra 5-line
calculation while doing first-pass only. Also, combline functions
to eliminate usage of intermediate buffer. This gives decoder a 3%
performance gain on my test clips.

Change-Id: I13de49638884d1a57d0855c63aea719316d08c1b

Using uname fails e.g. on a 64-bit machine with a 32-bit toolchain.
The following gcc -dumpmachine strings have been verified:
 * 32-bit Linux gives i486-linux-gnu
 * 64-bit Linux gives x86_64-linux-gnu
 * Mac OS X 10.5 gives i686-apple-darwin9
 * MinGW gives mingw32

*darwin8* and *bsd* can safely be assumed to be correct, but *cygwin*
is a guess.

Change-Id: I6bef2ab5e97cbd3410aa66b0c4f84d2231884b05