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.
Use correct context, reduce log level, don't assume it is a video stream,
and print the tag of the unknown stream.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Abort if it is invalid if strict error checking has been requested.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes crashes when playing back certain RealRTSP streams.
When invoked from the RTP depacketizer, the full realmedia
demuxer isn't invoked, but only certain functions from it, where
a separate AVIOContext is passed in as parameter (for the buffer
containing the data to parse). The functions called from within
those entry points should only be using that parameter, not
s->pb. In the depacketizer case, s is the RTSP context, where ->pb
is null.
Cc: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.
Replace it with the average framerate where it makes sense.
FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.
In some other tests lavf starts making up frame durations from different
frame.
Specifically, prevent jumping back in the file for the next index, since
this can lead to infinite loops where we jump between indexes referring
to each other, and don't read indexes that don't fit in the file.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
We read sub_packet_h / 2 packets per line of data (during deinterleaving),
which equals zero if sub_packet_h <= 1, thus causing us to not read any
data, leading to an infinite loop.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
This makes rdt work again, which has been broken since
603b8bc2a1. This commit made
opening a demuxer without a file (or in this case, with a filename
which can't be opened) fail, unless the demuxer actually declared
AVFMT_NOFILE.
Signed-off-by: Martin Storsjö <martin@martin.st>
Unlike other containers RealMedia stores its audio packets in scrambled form,
with interleaver ID preceeding audio codec ID. Currently deinterleaving
decision is tied to the codec while it's possible to have non-default
deinterleaver with audio codec (like Int0 deinterleaver instead of specific
one for Sipro).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
First, container stores only DTS and not PTS as it was believed.
Second, multiple frames in a packet store timestamp instead of position
after the frame length.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
