buffer when simply appending at the end works.
Much faster if one stream ends prematurely.
Fixes issue1379.
Originally committed as revision 19870 to svn://svn.ffmpeg.org/ffmpeg/trunk
are non-obvious and probably need a large (about 1kB at least) probe buffer.
Originally committed as revision 19850 to svn://svn.ffmpeg.org/ffmpeg/trunk
Require at least one signature match per provided 1MB of probe data,
and if there is only a single match, return at most MAX/4.
Fixes issue1382 but could/should probably still be improved.
Originally committed as revision 19848 to svn://svn.ffmpeg.org/ffmpeg/trunk
New code can detect h261 startcodes even when the first is damaged or not at the
begin. It also passes probetest v2 & v3.
Originally committed as revision 19845 to svn://svn.ffmpeg.org/ffmpeg/trunk
In particular check that the detected markers clearly indicate a specific DTS
format (a wild mixture of e.g. little- and big-endian markers is unlikely to be
a valid DTS file) and ensure the markers appear with sufficient frequency.
Originally committed as revision 19844 to svn://svn.ffmpeg.org/ffmpeg/trunk
In particular, check that length of the first index entries is not 0 since
that is interpreted "end of file" and makes no sense in the very first entries.
Originally committed as revision 19843 to svn://svn.ffmpeg.org/ffmpeg/trunk
invalid values that wouldn't play right anyway and reduce probe score to MAX/2.
Passes probetest v2.
Originally committed as revision 19842 to svn://svn.ffmpeg.org/ffmpeg/trunk
The new code should detect h263 even if the first startcode is damaged or
somewhere else than the first byte. It also passes probetest v2 as just
posted on ffmpeg-dev.
Originally committed as revision 19841 to svn://svn.ffmpeg.org/ffmpeg/trunk
This avoids a crash when the next slice is not a start slice and thus
pkt->data is still NULL.
This probably only happens with broken or unsupported files like
http://samples.mplayerhq.hu/real/multirate/JustaSpa1937_64kb.rm
that need further fixes, but keeping vst state consistent is still a good idea.
Originally committed as revision 19830 to svn://svn.ffmpeg.org/ffmpeg/trunk
At the moment, duration is mainly set from the metadata packet. If that is not
available, the fallback is checking the low 24 bits of the last packet. This is
not enough for files over 4,6 hours in length, so read all 32 bits instead.
patch by Martin Storsjö, martin martin st
Originally committed as revision 19791 to svn://svn.ffmpeg.org/ffmpeg/trunk
correct solution to the problem. A better solution might be possible later once
Speex is supported in muxers.
Originally committed as revision 19761 to svn://svn.ffmpeg.org/ffmpeg/trunk
av_find_stream_info(). It forces decoding of a packet when there is no
Speex header in order to determine the correct frame size.
Originally committed as revision 19760 to svn://svn.ffmpeg.org/ffmpeg/trunk
Michael Niedermayer
Justin Ruggles
Kostya Shishkov
Reimar Döffinger
Baptiste Coudurier
Benjamin Larsson
Ivan Schreter
shinya.tesutosan@hotmail.com
Maksym Veremeyenko
Martin Storsjö
Josh Harris