Compared to just overwriting the old extradata, this has the
advantage of letting the decoder know exactly when the
extradata changed (otherwise it is changed immediately when the
new extradata packet is demuxed, even if there's old queued packets
awaiting to be decoded). This makes it easier for decoders to
actually react to the change, so they won't have to inspect
the extradata for each packet to see if it might have changed.
This works when sequentially playing a file with sample rate
changes, but if seeking past a new extradata packet in the
file, it obviously doesn't work properly. That case doesn't
work in flash player either, so it's probably ok not to handle
it.
Signed-off-by: Martin Storsjö <martin@martin.st>
The existing functions defined in intfloat_readwrite.[ch] are
both slow and incorrect (infinities are not handled).
This introduces a new header with fast, inline conversion
functions using direct union punning assuming an IEEE-754
system, an assumption already made throughout the code.
The one use of Intel/Motorola extended 80-bit format is
replaced by simpler code sufficient under the present
constraints (positive normal values).
The old functions are marked deprecated and retained for
compatibility.
Signed-off-by: Mans Rullgard <mans@mansr.com>
It had become dead code when code was added to avoid
exporting audio and video codec id as metadata.
Untested due to lack of sample.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
instead of when the 2nd stream has been found.
This isnt ideal as we will likely still like before miss a data stream.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Pass the correct size in bits to mpeg4audio_get_config and add a flag
to disable parsing of the sync extension when the size is not known.
Latm with AudioMuxVersion 0 does not specify the size of the audio
specific config. Data after the audio specific config can be
misinterpreted as sync extension resulting in random and wrong configs.
Seems to fix trac issue #569.
Sample is unfortunately not available, but it might be caused by
an index existing for non-existing audio stream (?).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Manual replacements are done in this commit.
In many cases, the id is some constant made up number (e.g. 0 for video
and 1 for audio), which is then not used in the demuxer for anything.
Those ids are removed.
This avoids writing these entries doubly if transcoding from
flv to flv, since the muxer blindly writes any and all metadata
keys set, in addition to the fixed fields that the muxer
always writes.
Signed-off-by: Martin Storsjö <martin@martin.st>
On allocation, the array length is multiplied by sizeof(int64_t),
this prevents the multiplication from overflowing.
Signed-off-by: Martin Storsjö <martin@martin.st>
If there is only 1 stream in an flv avformat_find_stream_info will continually
read until probesize is reached. This should stop it reading if the metadata
also claims there to be 1 stream.
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>
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: Michael Niedermayer <michaelni@gmx.at>
'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>