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
duration and videodatarate values are actually useful
original patch from Art Clarke aclarke _at_ xuggle _dot_ com
Originally committed as revision 19363 to svn://svn.ffmpeg.org/ffmpeg/trunk
This has proven to be useless and even harmfull since r18460 (expect
for duration and videodatarate).
original patch from Art Clarke aclarke _at_ xuggle _dot_ com
Originally committed as revision 19362 to svn://svn.ffmpeg.org/ffmpeg/trunk
default values. This is needed because FLV files with Speex do not
contain a Speex header, which is necessary for stream copy.
Originally committed as revision 19267 to svn://svn.ffmpeg.org/ffmpeg/trunk
skipped metadata packet in FLV demuxer.
Patch by Art Clarke a${surname} At xuggle - com.
Originally committed as revision 19210 to svn://svn.ffmpeg.org/ffmpeg/trunk
and this is the easiest way to. It would be a lot of messy code we can drop
if it is useless.
As a sideeffect this fixes issue977.
Originally committed as revision 18460 to svn://svn.ffmpeg.org/ffmpeg/trunk
to have the total bitrate available in the avformat structures.
Patch by Stefan de Konink stefan konink de
Originally committed as revision 16943 to svn://svn.ffmpeg.org/ffmpeg/trunk
bits_per_coded_sample but that cannot be done seperately.
Patch by Luca Abeni
Also reset the minor version and fix the forgotton change to libfaad.
Note: The API/ABI should not be considered stable yet, there still may
be a change done here or there if some developer has some cleanup ideas and
patches!
Originally committed as revision 15262 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Stefano Sabatini, stefano.sabatini-lala poste.it
along with some spelling/consistency fixes for the long names by me
Originally committed as revision 13649 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
10l
Setting AVFMTCTX_NOHEADER if streams<2 so phantom streams are found.
fixes WELCOMETOBELGRADE.flv
After seeking bug has been fixed.
Originally committed as revision 12813 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
10l
Setting AVFMTCTX_NOHEADER if streams<2 so phantom streams are found.
fixes WELCOMETOBELGRADE.flv
As it unexpectly breaks seek regression tests.
Originally committed as revision 12811 to svn://svn.ffmpeg.org/ffmpeg/trunk
Setting AVFMTCTX_NOHEADER if streams<2 so phantom streams are found.
fixes WELCOMETOBELGRADE.flv
Originally committed as revision 12809 to svn://svn.ffmpeg.org/ffmpeg/trunk
Avoids some "Unsupported audio codec (6)" message in FLVs, e.g.
Example of such problematic bitstream is 'bad_codec6.flv'
in ftp's /incoming directory.
Originally committed as revision 12510 to svn://svn.ffmpeg.org/ffmpeg/trunk
Do what the spec says, insane or not:
"
Format 0 (uncompressed) and Format 3 (uncompressed little-endian) are similar. Both encode
uncompressed audio samples. For 8-bit samples, the two formats are identical. For 16-bit
samples, the two formats differ in byte ordering. In Format 0, 16-bit samples are encoded and
decoded according to the native byte ordering of the platform on which the encoder and Flash
Player, respectively, are running. In Format 3, 16-bit samples are always encoded in little-endian
order (least significant byte first), and are byte-swapped if necessary in Flash Player before
playback. Format 0 is clearly disadvantageous because it introduces a playback platform
dependency. For 16-bit samples, Format 3 is highly preferable to Format 0 for SWF version 4
or later.
"
Originally committed as revision 12184 to svn://svn.ffmpeg.org/ffmpeg/trunk
