Stop the avio input at a point where amf_parse_object can
continue parsing the end of the object seamlessly, when all
data is available.
If unsupported data is encountered within the keyframes object,
try seeking to the start of the keyframes object - if the seek
back was successful, the caller can continue parsing the rest
of the AMF data.
Signed-off-by: Martin Storsjö <martin@martin.st>
Current keyframes data parser unconditionally rewind metadata to
the end at the end of function. As result ALL metadata located
after keyframes index not parsed, and as metadata object can have
ANY placement inside metadata it can lead to unpredictable result
(bitrate can not be found, etc.). As result FLV movie will not
play at all in such situation.
Signed-off-by: Martin Storsjö <martin@martin.st>
'keyframes' metatag is not part of the standard, it is just
convention to use such kind of metatag information for indexing.
Structure is following, it allows to have it inconsistent:
keyframes:
times (array):
time0 (num)
time1 (num)
time2 (num)
filepositions (array)
position0 (num)
position1 (num)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
In the name of consistency:
get_byte -> avio_r8
get_<type> -> avio_r<type>
get_buffer -> avio_read
get_partial_buffer will be made private later
get_strz is left out becase I want to change it later to return
something useful.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
in its place.
av_metadata_set() is going to be dropped at the next major bump.
Originally committed as revision 22961 to svn://svn.ffmpeg.org/ffmpeg/trunk
Implement flv_read_seek(), add a missing check on stream_index
and fix timestamp rounding in rtmp_read_seek().
Also add the flv_read_seek2() function, which is not enabled but is
useful as reference.
To actually implement flv_read_seek2() correctly, there would need to
be some corresponding av_url_read_fseek2() function to propagate the
timestamps down to the ByteIOContext and URLContext.
Patch by Howard Chu <hyc <at> highlandsun.com>.
See the thread:
Subject: [FFmpeg-devel] RTMP seek support
Date: 2010-03-28 23:35:02 GMT
Originally committed as revision 22904 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
Use AV_METADATA_DONT_STRDUP* / use av_malloced metadata instead of strduped
arrays of fixed length.
Code from ffmbc with changes to adapt to our metadata API.
Reason: memleak & fix is not trivial
Originally committed as revision 20866 to svn://svn.ffmpeg.org/ffmpeg/trunk
arrays of fixed length.
Code from ffmbc with changes to adapt to our metadata API.
Originally committed as revision 20836 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
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
patch by: Björn Axelsson, bjorn d axelsson a intinor d se
thread: [PATCH] Remove static ByteIOContexts, 06 nov 2007
Originally committed as revision 11071 to svn://svn.ffmpeg.org/ffmpeg/trunk
Those files really contain 2 standard VP6 video streams:
- the "normal" video stream
- the alpha plan video stream (which is a standard
YV12 video with it's U an V plans all set to 0)
closes issue166
Originally committed as revision 10527 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Allan Hsu % allan A counterpop P net %
date: Dec 12, 2006 12:19 PM
subject: Re: [Ffmpeg-devel] [PATCH] FLV decoder metadata reading
Originally committed as revision 7286 to svn://svn.ffmpeg.org/ffmpeg/trunk
