ADTS frames may contain up to 768 bytes per channel. With 16 channels,
this is 12k, which cannot fit into the maximum 8k buffer.
Signed-off-by: Chris Ribble <chris.ribble@resi.io>
Fixes: signed integer overflow: 9223372036840103978 + 67637280 cannot be represented in type 'long'
Fixes: 33341/clusterfuzz-testcase-minimized-ffmpeg_dem_DSF_fuzzer-6408154041679872
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 9223372036854775805 + 4 cannot be represented in type 'long'
Fixes: 29927/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5579985228267520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 32 + 2147483647 cannot be represented in type 'int
Fixes: 32967/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-5132856218222592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 9223372036846336888 + 4278255871 cannot be represented in type 'long'
Fixes: 32782/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6059216516284416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -1184429040541376544 * 32 cannot be represented in type 'long'
Fixes: 31788/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-6236746338664448
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This would only make a difference in case the first attempt to
initialize the encoder failed and the second succeeded. The only
reason I can think of for this to happen is that the options (in
particular the codec whitelist) are not used for the second try
and that obviously implies that we should not even try a second time
to open the decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ffio_fill() is used when initially writing unknown length elements;
yet it can happen that the amount of bytes written by it is zero in
which case it is of course unnecessary to ever call it. Whether it is
possible to know this during compiletime depends upon how aggressively
the compiler inlines function calls (i.e. if it inlines calls to
start_ebml_master() where the upper bound for the size of the element
implies that the size will be written on one byte) and this depends upon
optimization settings. It is not the aim of this patch to inline all
calls where it is known that ffio_fill() will be unnecessary, but merely
to make compilers that inline such calls aware of the fact that writing
zero bytes with ffio_fill() is unnecessary. To this end
av_builtin_constant_p() is used to check whether the size is a
compiletime constant.
For GCC 10 this made a difference at -O3 only: The size of .text
decreased from 0x747F (with 29 calls to ffio_fill(), eight of which
use size zero) to 0x7337 (with 21 calls to ffio_fill(), zero of which
use size zero).
For Clang 11 it made a difference at -O2 and -O3: At -O2, the size of
.text decreased from 0x879C to 0x871C (with eight calls to ffio_fill()
eliminated); at -O3 the size of .text decreased from 0xAF2F to 0xAEBF.
Once again, eight calls to ffio_fill() with size zero have been
eliminated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now the cover images will get the stream index 0 in this case,
violating the hardcoded assumption that this is the index of the audio
stream. Fix this by creating the audio stream first; this is also in
line with the expectations of ff_pcm_read_seek() and
ff_spdif_read_packet(). It also simplifies the code to parse the fmt and
xma2 tags.
Fixes#8540; regression since f5aad350d3.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is simpler and more complete (e.g. it copies the framerate
information which allows to write the default duration element).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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>
write_header() already checks that there are only video tracks besides
the one audio track.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't blindly copy all bytes in extradata past ChannelMappingFamily. Instead
check if ChannelMappingFamily is not 0 and then only write the correct amount
of bytes from ChannelMappingTable, as defined in the spec[1].
Fixes part of ticket #9190.
[1] https://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
Signed-off-by: James Almer <jamrial@gmail.com>
The libwebp_animencoder returns a single packet with the entire animated
stream, as that's what the external library produces. As such, only ensure the
stream was produced by said encoder (or propagated by a demuxer, once support
is added) when attempting to write the requested loop value.
Fixes ticket #9179.
Signed-off-by: James Almer <jamrial@gmail.com>
From the ISO/IEC specification for MP4:
The pixel aspect ratio and clean aperture of the video may be specified
using the ‘pasp’ and ‘clap’ sample entry boxes, respectively. These are
both optional; if present, they over-ride the declarations (if any) in
structures specific to the video codec, which structures should be
examined if these boxes are absent. For maximum compatibility, these
boxes should follow, not precede, any boxes defined in or required by
derived specifications.
Fixes trac/#7277.
Currently, the DASH demuxer omits the final segment for a non-live
stream (using SegmentTemplate) if it is shorter than the other segments.
Correct calc_max_seg_no to round up when calulating the number of
segments instead of rounding down to resolve this issue.
Signed-off-by: Matt Robinson <git@nerdoftheherd.com>
The value zero for AVPacket.duration means that the duration is unknown,
which in practice means "play this subtitle until overridden by the next
subtitle". Yet for Matroska a BlockGroup with duration zero means
that the subtitle really has a duration zero. "Display until overridden"
is achieved by not setting a duration on the container level at all and
this is achieved by using a SimpleBlock or a BlockGroup without
duration. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: left shift of negative value -224
Fixes: 32144/clusterfuzz-testcase-minimized-ffmpeg_dem_MVI_fuzzer-4971479323246592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Apparently for various image sequences libavformat/utils.c can
calculate rather fancy r_frame_rate values, such as `186/1921`,
and since ffmpeg.c utilizes r_frame_rate for the filter chain
time base, this can quite deteriorate the output frame timing - even
though the user has requested the image sequence to be interpreted
at a specific, constant frame rate.
For both the RealMedia as well as the IVR demuxer (which share the same
context) each AVStream's priv_data contains an AVPacket that might
contain data (even when reading the header) and therefore needs to be
unreferenced. Up until now, this has not always been done:
The RealMedia demuxer didn't do it when allocating a new stream's
priv_data failed although there might be other streams with packets to
unreference. (The reason for this was that until recently rm_read_close()
couldn't handle an AVStream without priv_data, so one had to choose
between a potential crash and a memleak.)
The IVR demuxer meanwhile never ever called read_close so that the data
already contained in packets leaks upon error.
This patch fixes both demuxers by adding the appropriate cleanup code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All one needs is one byte beyond the end of the normal data; and because
the packet is padded, one already has it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current code tries the access the codecpar of a nonexistent
audio stream when seeking. Stop that. Fixes ticket #9121.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The DSS demuxer currently decrements a counter that should be positive
at the beginning of read_packet; should it become negative, it means
that the data to be read can't be read contiguosly, but has to be read
in two parts. In this case the counter is incremented again after the
first read if said read succeeded; if not, the counter stays negative.
This can lead to problems in further read_packet calls; in tickets #9020
and #9023 it led to segfaults if one tries to seek lateron if the seek
failed and generic seek tried to read from the beginning. But it could
also happen when av_new_packet() failed and the user attempted to read
again afterwards.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Chris Ribble
Michael Niedermayer
Marton Balint
Andreas Rheinhardt
James Almer
Gyan Doshi
Vittorio Giovara
Matt Robinson
Jan Ekström
Anton Khirnov