Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
For http, this avoids spurious warnings about failed requests (e.g.
HTTP error 416 Requested Range Not Satisfiable), if the last packet
is truncated and the size read is bogus.
Signed-off-by: Martin Storsjö <martin@martin.st>
When loading a truncated flv file, it would previously try to do a seek to
the end of every packet read. For some input protocols (such as http), such
repeated seek attempts are cripple the reading performance.
Signed-off-by: Martin Storsjö <martin@martin.st>
The current muxer behaviour is to create streams in read_header() based
on the audio/video presence flags, but fill in the stream parameters
later when we actually get some packets for them. This is rather shady,
since other demuxers set the stream parameters immediately when the
stream is created and do not touch the stream codec context after that.
Change the flv demuxer to behave in the same way as other similar
demuxers -- create the streams only when we get a packet for them.
Currently, only onMetaData is used, but some providers (wrongly)
put metadata into onCuePoint events, and it's still nice to be
able to use that data.
onCuePoint events also present metadata slightly differently than
onMetaData events: all metadata is found inside an object called
"parameters". In order to extract this metadata, it's easiest to
recurse through the object tree and pull out anything found in
child objects and put it in the top-level metadata.
Reference: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/2/help.html?content=00001404.html
Signed-off-by: Anton Khirnov <anton@khirnov.net>
If no streams were indicated in the FLV header, do not automatically
allocate by default a video and an audio stream. Instead, in the case
that the header did not indicate the presence of any data, allocate no
stream until data actually arrives for one type.
Signed-off-by: Martin Storsjö <martin@martin.st>
The Omnia A/XE encoder writes the explicit extra data incorrectly
and wrongly disables parametric stereo. Truncating the extra data
by setting the size to 2 works around this. The AAC extra data
parser will then only parse the correct parts.
Bug-id: 599
The callers of this function can't report errors sanely. If this
one malloc fails, don't write the extradata byte, make sure we
try to malloc it the next time we're called instead, and make sure
we still consume the input data byte.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This header byte is only present when actually reading a VP6 frame,
not when reading the codec type field in the metadata. This
potential bug has been present since 5b54a90c.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids creating new AVStreams for them when switching between
different variants of them, since we can handle changes between
different sample rates of nellymoser within the same stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
The sample_rate variable is used for checks for audio format
changes at the end of the function.
This fixes cases where the sample rate was set from the codec
id by flv_set_audio_codec (as for nellymoser 8 kHz/16 kHz),
so the value set to last_sample_rate wasn't equal to sample_rate
at this point. This caused the demuxer otherwise reports a spurious
change to 5512 Hz and back to the correct one.
Updating channels in the same way is only done for consistency.
Currently, flv_set_audio_codec doesn't update that value.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also add missing trailing commas, break long codec_tag lines and
add spaces in codec_tag declarations.
Signed-off-by: Martin Storsjö <martin@martin.st>
By validating the index entries while reading, we don't need to
seek at startup to validate the entries. If the error in the
index entries is not pointing to (our definition of) the start
of packets, and there is an index entry pointing at some of the
first packets after the metadata, the invalid index can be discarded
almost immediately.
Signed-off-by: Martin Storsjö <martin@martin.st>
