This commit does for AVInputFormat what commit
59c9dc82f4 did for AVOutputFormat:
It adds a new type FFInputFormat, moves all the internals
of AVInputFormat to it and adds a now reduced AVInputFormat
as first member.
This does not affect/improve extensibility of both public
or private fields for demuxers (it is still a mess due to lavd).
This is possible since 50f34172e0
(which removed the last usage of an internal field of AVInputFormat
in fftools).
(Hint: tools/probetest.c accesses the internals of FFInputFormat
as well, but given that it is a testing tool this is not considered
a problem.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by allocating AVStream together with the data that is
currently in AVStreamInternal; or rather: Put AVStream at the
beginning of a new structure called FFStream (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVStreamInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When parsing ID3v2 tags, special (non-text) metadata is not applied
directly and unconditionally; instead it is stored in a linked list
in which elements are prepended. When traversing the list to add APICs
(or private tags) at the end, the order is reversed. The same also
happens for chapters and therefore the chapter parsing code already
reverses the chapters.
This commit changes this: By keeping pointers to both head and tail
of the linked list one can preserve the order of the entries and
remove the reordering code for chapters. Only the pointer to head
will be exported: No current caller uses a nonempty list, so exporting
both head and tail is unnecessary. This removes the functionality
to combine the lists of special metadata read from different ID3v2 tags,
but that doesn't make really much sense anyway (and would be trivial
to implement if desired) and allows to remove the now unnecessary
initializations performed by the callers.
The FATE-reference for the id3v2-priv test had to be updated
because the order of the tags read into the dict is reversed;
for id3v2-priv-remux only the md5 and not the ffprobe output
of the remuxed file changes because the order of the private tags
has up until now been reversed twice.
The references for the aiff/mp3 cover-art tests needed to be updated,
because the order of the attached pics is reversed upon reading.
It is still not correct, because the muxers write the pics in the order
in which they arrive at the muxer instead of the order given by
pkt->stream_index.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes possible leaks of id3v2 metadata as well as an AVDES struct in
case the content is encrypted and an error happens lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_id3v2_parse_apic/chapters/priv/priv_dict all had a parameter
extra_meta of type ID3v2ExtraMeta ** as if the functions wanted to make
*extra_meta point to something else. But they don't, so just use an
ID3v2ExtraMeta *.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the ID3v2ExtraMeta structure (which is used when parsing
ID3v2 tags containing attached pictures, chapters etc.) contained a
pointer to separately allocated data that depended on the type of the
tag. Yet the difference of the sizes of the largest and the smallest of
these structures is fairly small, so that it is better to simply include
a union of all the possible types of tag-dependent structures in
ID3v2ExtraMeta. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is not uncommon to find code where the caller thinks to know better
what the return value should be than the callee. E.g. something like
"if (av_new_packet(pkt, size) < 0) return AVERROR(ENOMEM);". This commit
changes several instances of this to instead forward the actual error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These changes store id3 chapter data in ID3v2ExtraMeta and introduce
ff_id3v2_parse_chapters to parse them into the format context if needed.
Encoders using ff_id3v2_read, which previously parsed chapters into the
format context automatically, were adjusted to call
ff_id3v2_parse_chapters.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
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.
Several chunked formats (AIFF, IFF,DSF) store ID3 metadata within an 'ID3 '
chunk tag. If such chunks are stored sequentially, it is possible for the
ID3v2 parser to confuse the chunk tag for the ID3 magic number. e.g.
[1st chunk tag ('ID3 ') | chunk size] [ID3 magic number | metadata ...]
[2nd chunk tag ('ID3 ') | chunk size] [ID3 magic number | metadata ...]
Fixes ticket #3530.
Signed-off-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Imporoves detection of some files in the wild:
- ID3v2 a.k.a. "ea3" header is optional.
- Version and flags in ID3v2 header are unspecified.
Signed-off-by: David Goldwich <david.goldwich@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Incomplete crypted files would lead to a read after buffer boundary
otherwise.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Andreas Rheinhardt
Vittorio Giovara
James Almer
Andreas Rheinhardt
Carl Eugen Hoyos
Lukas Stabe
Carl Eugen Hoyos
Paul B Mahol
Andreas Cadhalpun
Anton Khirnov
Michael Niedermayer
Michael Niedermayer
Luca Barbato
Peter Ross
Diego Biurrun
Maxim Polijakowski
David Goldwich
Martin Storsjö