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
perform interpolation steps in such an order that halfpel interpolation
could be done per picture
this also makes mc_block() match h.264 for the 1/4 pel cases so that the
use of the h264 functions for some cases does not introduce a fantastic mess
Originally committed as revision 10433 to svn://svn.ffmpeg.org/ffmpeg/trunk
the old 32bit code)
disable mmx/sse2 optimizations as they need a rewrite now
Originally committed as revision 10218 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows some simplifications and optimizations and should
not have any effect on quality.
Originally committed as revision 10172 to svn://svn.ffmpeg.org/ffmpeg/trunk
