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>
ff_id3v2_parse_priv_dict() uses av_dict_set() with the flags
AV_DICT_DONT_STRDUP_KEY and AV_DICT_DONT_STRDUP_VAL. In this case both
key and value are freed on error (and owned by the destination
dictionary on success), so that freeing them again on error is a
double-free and therefore forbidden. But it nevertheless happened.
Fixes CID 1452489 and 1452421.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avio_read may return EOF, leaving the mimetype array unitialized. fail
early when this occurs to avoid using the array in an unitialized state.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
sequences with 0xFF. This has to be done on every byte of the source
data, while the current code skipped a byte after a replacement. This
meant 0xFF 0x00 0xFF 00 was translated to 0xFF 0xFF 0x00 instead of 0xFF
0xFF. It feels a bit messy to do this correctly with the avio use. But
fortunately, this translation can be done in-place, so we can just do it
in memory.
Inspired by what taglib does.
Also see 9ae80e6a9c. (The sample file for
that commit is gone, so it could not be retested.)
Enables getting access to ID3 PRIV tags from the command-line or metadata API
when demuxing. The PRIV owner is stored as the metadata key prepended with
"id3v2_priv.", and the data is stored as the metadata value. As PRIV tags may
contain arbitrary data, non-printable characters, including NULL bytes, are
escaped as \xXX.
Similarly, any metadata tags that begin with "id3v2_priv." are inserted as ID3
PRIV tags into the output (assuming the format supports ID3). \xXX sequences in
the value are un-escaped to their byte value.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
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.
The APIC description must be unique, and some ID3v2 tag writers add
spaces to write several APIC entries with the same description. The
trailing spaces simply serve as a way to disambiguate the description.
Do this so that API users do not have to special-case mp3 to fix this
cosmetic issue.
Requested-by: wm4
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since len is an unsigned int, the comparison is currently treated as
unsigned and thus ignores all errors from avio_read.
Thus cast len to int, which is unproblematic, because at that point len
is between 0 and 4.
This fixes 'Conditional jump or move depends on uninitialised value'
valgrind warnings in is_tag.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
APIC tags always have a description. Tag writers obviously leave it
empty if there is no description. In this case, libavformat would export
"" as title. Do not set the title instead.
APIC tags always have a description. Tag writers obviously leave it
empty if there is no description. In this case, libavformat would export
"" as title. Do not set the title instead.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
I think this turned out pretty terrible. There's no good way to add new
custom tags that write to AVFormatContext->metadata.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
TDRL is what we used as a replacement of TYER, and, according to
http://id3.org/id3v2.4.0-changes :
TYER - Year
This frame is replaced by the TDRC frame, 'Recording time'
[F:4.2.5].
So change TDRL usages to TDRC.
Fixes ticket #3694
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some encoders do not use syncsafe sizes in v2.4 id3 tags. Check the next
tag to try to choose between the two.
Fixes ticket #4003
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
Add ff_id3v2_read_dict() for parsing without AVFormatContext, but
instead with AVIOContext and AVDictionary.
AVFormatContext is still used for logging, if available.
Chapter parsing is the only non-logging functionality that actually
needs AVFormatContext, and AFAICS it should be modified to write the
data to ID3v2ExtraMeta first, from where it can be implanted to
AVFormatContext by a separate function (like it is done with
read_apic() and ff_id3v2_parse_apic()). That is outside the scope of
this patch, though.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Fixes use of uninitialized memory
Fixes: msan_uninit-mem_7f5a04a9b50d_7087_mp3__mp3__tooSmallFinal.mp3
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>