seeking before data_offset and is more consistent with how the generic index
seeking code handles it.
Originally committed as revision 17964 to svn://svn.ffmpeg.org/ffmpeg/trunk
for swf before and after, but it now incorrectly creates additional
streams.
Originally committed as revision 17913 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
The matroska demuxer now index every streams so seek on stream 1 now works.
Originally committed as revision 15254 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
This change is due to r14590.
The AVPacket position now points to the first byte of the actual
packet data in the file. It previously pointed to the EBML element
ID preceding packet data.
Originally committed as revision 14612 to svn://svn.ffmpeg.org/ffmpeg/trunk
contains the first picture startcode that commences in the PES
packet, instead of the first access unit that commences in the
PES packet. Fix the parser to
handle that properly. This was a very long standing bug ...
The change to the seek regressions is because the mpeg ts muxer
stores too many invalid and randomized timestamps which overflow
the 4 entry buffer we use in the parser.
Originally committed as revision 13643 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
and the information needed to guess the duration only becomes known at a later packet.
Originally committed as revision 11963 to svn://svn.ffmpeg.org/ffmpeg/trunk
This only removes 2 bytes from MP3 and MP2 currently.
Up to 4 could be removed from MP3/MP2 though this might need a 2pass muxer.
Primitive code to remove headers from MPEG-1/2/4 is there too but for the
single file I tried it on (the one in the regression tests), it was a loss
because all video frames were >4096 byte, so that it is disabled ATM.
Originally committed as revision 11936 to svn://svn.ffmpeg.org/ffmpeg/trunk
Baptiste Coudurier
Reimar Döffinger
Justin Ruggles
Ivan Schreter
Michael Niedermayer
Aurelien Jacobs
Stefan de Konink
David Conrad
Panagiotis Issaris
Måns Rullgård
Kostya Shishkov