Fixes issue 975: high db peak levels when encoding mp2
Original patch by Lasse Reinhold, lassemikkelreinhold hotmail
Originally committed as revision 20100 to svn://svn.ffmpeg.org/ffmpeg/trunk
The specification does not say which value to use for unused
parts, so fill all unused bytes with 0xff, which is consistent
with what DV usually uses for reserved or unused parts.
Originally committed as revision 20084 to svn://svn.ffmpeg.org/ffmpeg/trunk
single index chunk) and is always empty anyway. See "[PATCH] rmenc.c: remove
index writing" thread.
Originally committed as revision 18119 to svn://svn.ffmpeg.org/ffmpeg/trunk
AC-3 decoding regression test fails with gcc 2.95.3 because of missing
SSE support.
Originally committed as revision 15625 to svn://svn.ffmpeg.org/ffmpeg/trunk
Plain C, x86-32 and -64 have been tested and should work, other
archs that had asm optmizations in swscale likely will need some fixes
to either fall back on C if SWS_BITEXACT is set or make the asm match C.
This also disables the PAL8 test as neither swscale nor the old scaler
really support PAL8 output, imgconvert supported a fixed 666 palette
as output and swscale supports fixed 884 and 422.
Originally committed as revision 15305 to svn://svn.ffmpeg.org/ffmpeg/trunk
residuals, Note this does not change RGB32 as we need to check this
against some decoder that supports it.
Originally committed as revision 15055 to svn://svn.ffmpeg.org/ffmpeg/trunk
Also display both file sizes and slightly change the output formatting.
[not split in 3 patches to avoid the huge checksum files from being changed
and having to be reviewed 3 times, if people want it split i can revert and
split it]
Originally committed as revision 14374 to svn://svn.ffmpeg.org/ffmpeg/trunk
The PSP MP4 format requires an AAC audio stream, so until
we have an AAC encoder we cannot test this format.
The existing test is broken and does not actually use the
PSP format.
Originally committed as revision 12359 to svn://svn.ffmpeg.org/ffmpeg/trunk
through lrintf(), that is gcc put the 32bit int flags in a 32bit float
which caused some to be lost ...).
I wonder why FATE did not pick this up?
Originally committed as revision 12329 to svn://svn.ffmpeg.org/ffmpeg/trunk
in block in adpcm-ima decoder
Patch by Timofei V. Bondarenko: tim £ ipi, ac, ru
Original thread: [FFmpeg-devel] [PATCH] adpcm-ima-wav header and codec
Date: 10/15/2007 05:55 PM
Originally committed as revision 10933 to svn://svn.ffmpeg.org/ffmpeg/trunk
these were wrong (in pts vs dts sense) when b frames were in use
they were also wrong if the average framerate was smaller than 1/timebase
resulting in totally wrong final bitrate
Originally committed as revision 10477 to svn://svn.ffmpeg.org/ffmpeg/trunk
flag for diagonal interpolation
the primary reason for this change is that previously MC up to 1/4 pel
matched H.264 exactly and that increases the risk of stumbling over
patents
secondly this allows 0.10 db or more quality gain by choosing a longer
filter and the filter could also be chosen optimally for each frame
though that of course would cause speed loss at the decoder and encoder
side ...
Originally committed as revision 10436 to svn://svn.ffmpeg.org/ffmpeg/trunk
Lasse Reinhold
Reimar Döffinger
Måns Rullgård
Yoshihisa Uchida
Larbi Joubala
Baptiste Coudurier
Michael Niedermayer
Ronald S. Bultje
Stefan de Konink
David Conrad
Carl Eugen Hoyos
Justin Ruggles
Peter Ross
Aurelien Jacobs
Henrik Gulbrandsen
Kostya Shishkov
Benjamin Larsson
Timofei V. Bondarenko
Benoit Fouet