patch by Robert Swain.
probably this change is caused by the flags2 default change
why ohh why does noone run the regression tests before cvs commit :(
Originally committed as revision 4845 to svn://svn.ffmpeg.org/ffmpeg/trunk
Note, if you think thats too harsh, look at the cvs history he has broken the regression tests many times and has not once
updated the checksums ...
regression test checksum change due to: movenc.c 1.46->1.47
"finally found what those >138 codes were... crappy compressed 5bit ascii. this gets them correctly, and adds setting track"
Originally committed as revision 4826 to svn://svn.ffmpeg.org/ffmpeg/trunk
so they always appear in proper order.
patch by Sam Hocevar < sam -- at -- zoy -- dot -- org >
Originally committed as revision 4606 to svn://svn.ffmpeg.org/ffmpeg/trunk
dc coeff rounding fix
class=3 num of bits fix
do interlaced check & idct only if CODEC_FLAG_INTERLACED_DCT
Originally committed as revision 4542 to svn://svn.ffmpeg.org/ffmpeg/trunk
note, none of the files is playable but this test should help against further breakage unless of course the checksums depend upon something they shouldnt
Originally committed as revision 4456 to svn://svn.ffmpeg.org/ffmpeg/trunk
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
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
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
Loren Merritt
Diego Biurrun
Michael Niedermayer
Robert Swain
Alex Beregszaszi
Sam Hocevar
Justin Ruggles
Roine Gustafsson
Yartrebo