A single VorbisComment consists of a length field and a
non-NUL-terminated string of the form "key=value". Up until now,
when parsing such a VorbisComment, zero-terminated duplicates of
key and value would be created. This is wasteful if these duplicates
are freed shortly afterwards, as happens in particular in case of
attached pictures: In this case value is base64 encoded and only
needed to decode the actual data.
Therefore this commit changes this: The buffer is temporarily modified
so that both key and value are zero-terminated. Then the data is used
in-place and restored to its original state afterwards.
This requires that the buffer has at least one byte of padding. All
buffers currently have AV_INPUT_BUFFER_PADDING_SIZE bytes padding,
so this is ok.
Finally, this also fixes weird behaviour from ogm_chapter():
It sometimes freed given to it, leaving the caller with dangling
pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Without end_trimming, the last packet will contain unexpected samples used
for padding.
This commit partially fixes#6367 when the audio length is long enough.
dd if=/dev/zero of=./silence.raw count=20 bs=500
oggenc --raw silence.raw --output=silence.ogg
oggdec --raw --output silence.oggdec.raw silence.ogg
ffmpeg -codec:a libvorbis -i silence.ogg -f s16le -codec:a pcm_s16le silence.libvorbis.ffmpeg.raw
ffmpeg -i silence.ogg -f s16le -codec:a pcm_s16le silence.native.ffmpeg.raw
ls -l *.raw
The original test case in #6367 is still not fixed due to a remaining issue.
The remaining issue is that ogg_stream->private is not kept during
ogg_save()/ogg_restore(). Field final_duration in the private data is
important to calculate end_trimming.
Some common operations such as avformat_open_input() and
avformat_find_stream_info() before reading packet will trigger ogg_save()
and ogg_restore().
Luckily, final_duration will not get updated until the last ogg page. The
save/restore mentioned above will not change final_duration most of the
time. But if the audio length is short, those reads may be performed on
the last ogg page, causing trouble keeping the correct value of
final_duration. We probably need a more complicated patch to address this
issue.
Signed-off-by: Guangyu Sun <gsun@roblox.com>
Some flac muxers write truncated metadata picture size if the picture
data do not fit in 24 bits. Detect this by truncting the size found inside
the picture block and if it matches the block size use it and read rest
of picture data.
This workaround is only for flac files and not ogg files with flac
METADATA_BLOCK_PICTURE comments and it can be disabled with strict level
above normal. Currently there is a 500MB limit on truncate size to protect
from large memory allocations.
The truncation bug in lavf flacenc was fixed in e447a4d112
but based on existing broken files other unknown flac muxers seems to truncate also.
Before the fix a broken flac file for reproduction could be generated with:
ffmpeg -f lavfi -i sine -f lavfi -i color=red:size=2400x2400 -map 0:0 -map 1:0 -c✌️0 bmp -disposition:1 attached_pic -t 1 test.flac
Fixes ticket 6333
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Regression since 8d3630c540 where keys were changed
to not be touppered but the picture block strcmp was not changed to be case-insensitive.
Fixes ticket #8608.
This will likely also fix CID 1452427, a false positive resulting from
Coverity thinking that av_dict_set() automatically frees its key and
value parameters (even without the AV_DICT_DONT_STRDUP_* flags).
(AV_DICT_APPEND and AV_DICT_DONT_STRDUP_VAL are compatible with each
other since a8c5b455, so we can reset this flag here. It has originally
been removed in 0dc66553 when appending was added.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The spec in https://xiph.org/vorbis/doc/v-comment.html states that
the metadata keys are case-insensitive, so don't change the case
and update the fate test case.
Fix#7784
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Fixes ticket #6804. All of the ogg header and packet parsers may
return standard AVERROR codes; these return values should not be
treated as success.
Additionally changes oggparsevorbis, to not give up too early
with certain types of poorly muxed files.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It has no use afterwards and freeing it before calling ff_flac_parse_picture()
may help prevent OOM issues on memory constrained scenarios.
Signed-off-by: James Almer <jamrial@gmail.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.
Originally, AVFormatContext and a metadata dict were provided to ff_vorbis_comment(),
but this presented issues if an AVStream was being updated or the metadata on
AVFormatContext wasn't actually being updated. To remedy this, ff_vorbis_stream_comment()
explicitly updates a stream's metadata and sets any necessary flags.
ff_vorbis_comment() does not modify any flags, and any calls to it that update
AVFormatContext's metadata (just a single call) must also update
AVFormatContext.event_flags after detecting any metadata changes to the provided
dictionary, as signaled by a positive return value.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes out of array read
Fixes: 34260c7981118fb38fba61809bf4dd5a-asan_heap-oob_93b923_1508_cov_951051643_DivX640x480_oggvorbis.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If a special comment packet shows up in the middle of the stream, we
should extract it out into the vorbis stream metadata dictionary.
Also, if there is metadata in the packet on the way in, it might linger
since we only add data to the dictionary causing stale metadata to be
inserted into the stream. Instead, clear it to remove any doubt about
what is new and old.
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Currently, if there are multiple 'performer' tags, the last one is the
only one which appears. Instead, join them with a semicolon.
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When av_reallocp fails, the associated variables that keep track of
the number of elements in the array (and in some cases, the
separate number of allocated elements) need to be reset.
Not all of these might technically be needed, but it's better to
reset them if in doubt, to make sure variables don't end up
conflicting.
Signed-off-by: Martin Storsjö <martin@martin.st>
It is possible to have an initial broken header and then valid packets.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Vittorio Giovara
Andreas Rheinhardt
Guangyu Sun
Andreas Rheinhardt
Michael Niedermayer
Mattias Wadman
Jun Zhao
Dale Curtis
James Almer
Alexandra Hájková
Anton Khirnov
Luca Barbato
Michael Niedermayer
Andrew Stone
Carl Eugen Hoyos
Alessandro Ghedini
Hendrik Leppkes
Ben Boeckel
Martin Storsjö
Alexandra Khirnova
Reimar Döffinger