be fixed even without adding the feature.  The output correctly uses 4
dummy values for the rematrixing flags in block-0, but the bit
allocation routine does not take these bits into account.  From what I
can tell, there was a patch in 2003 that corrected the output to make it
DVD and spec compatible, but it didn't correct the bit allocation.  It's
only 4 bits over the entire 6 blocks, so overflow errors would happen
rarely or never, but it's still worth fixing.  So here is a fix.

patch by (Justin Ruggles {jruggle earthlink net)

Originally committed as revision 4179 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4178 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4177 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4175 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4174 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4173 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4171 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4168 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4162 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4161 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4159 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4158 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4157 to svn://svn.ffmpeg.org/ffmpeg/trunk

instead of doing a case where we should add lot's of versions.
patch by (matthieu castet {castet.matthieu free fr)

Originally committed as revision 4156 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4155 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4154 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4153 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4151 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4150 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4149 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4148 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4147 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4146 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4144 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4143 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4142 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4141 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4140 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4139 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4137 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4136 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4135 to svn://svn.ffmpeg.org/ffmpeg/trunk

patch by Bret Hughes <bhughes at elevating dot com>

Originally committed as revision 4134 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4133 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4132 to svn://svn.ffmpeg.org/ffmpeg/trunk

about 10% lower bitrate for -qscale 32 (forman & some music video)
worst case bitrate increase <0.1% (lossless or low qscale)
and now the bad news, even though this just adds a single subtraction and an if() into the medium sized unpack_coeffs() loop and the if() will only be false once per unpac_coeff() call, gcc produces 50% slower code, i didnt look at the generated asm yet, not sure if i want to ...

Originally committed as revision 4131 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4130 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4129 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4128 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4127 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4126 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4124 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4119 to svn://svn.ffmpeg.org/ffmpeg/trunk

this is needed as the quantization stepsize for each subband is also in this precission and insignificant changes to the wavelet like scaling its coefficients slightly differently would lead to wildly variing PSNR and bitrate
note, a encoder could also simply choose to leave the least significant bits of the quantization parameters zero which would give the exact previous behaviour except a y very tiny number of bits in  the header

Originally committed as revision 4115 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4114 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Jindrich Makovicka

Originally committed as revision 4112 to svn://svn.ffmpeg.org/ffmpeg/trunk

Fixes locoRGBA.avi (the file is really YV12, even if it's called RGBA)

Originally committed as revision 4111 to svn://svn.ffmpeg.org/ffmpeg/trunk

This patch corrects the support for I slice in CABAC and MBAFF mode.
This decodes correctly 6 more frames of the conformance suite.

Originally committed as revision 4109 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4108 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4107 to svn://svn.ffmpeg.org/ffmpeg/trunk