Instead use ffio_read_size to read data into a buffer. Also check that
the desired size was actually successfully read and combine the check
with the check for reading the extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Allocating two arrays with the same number of elements together
simplifies freeing them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
A Smacker file can contain up to seven audio tracks. Up until now,
the pts for the i. audio packet contained in a Smacker frame was
simply the end timestamp of the last i. audio packet contained in
an earlier Smacker frame.
The problem with this is that a Smacker stream need not contain data in
every Smacker frame and so the current i. audio packet present may come
from a different underlying stream than the last i. audio packet
contained in an earlier frame.
The sample hypnotix.smk* exhibits this. It has three audio tracks and
the first of the three has a longer first packet, so that the audio for
the first track is contained in only 235 packets contained in the first
235 Smacker frames; the end timestamp of this track is 166696 (about 7.56s
at a timebase of 1/22050); the other two audio tracks both have 253 packets
contained in the first 253 Smacker frames. Up until now, the 236th
packet of the second track being the first audio packet in the 236th
Smacker frame would get the end timestamp of the last first audio packet
from the last Smacker frame containing a first audio packet and said
last audio packet is the first audio packet from the 235th Smacker frame
from the first audio track, so that the timestamp is 166696. In contrast,
the 236th packet from the third track (whose packets contain the same number
of samples as the packets from the second track) has a timestamp of
156116 (because its timestamp is derived from the end timestamp of the
235th packet of the second audio track). In the end, the second track
ended up being 177360/22050 s = 8.044s long; in contrast, the third
track was 166780/22050 s = 7.56s long which also coincided with the
video.
This commit fixes this by not using timestamps from other tracks for
a packet's pts.
*: https://samples.ffmpeg.org/game-formats/smacker/wetlands/hypnotix.smk
Reviewed-by: Timotej Lazar <timotej.lazar@araneo.si>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The layout of a Smacker frame is as follows: For some frames, the
beginning of the frame contained a palette for the video stream; then
there are potentially several audio frames, followed by the data for the
video stream.
The Smacker demuxer used to read the palette, then cache every audio frame
into a buffer (that gets reallocated to the desired size every time a
frame is read into this buffer), then read and return the video frame
(together with the palette). The cached audio frames are then returned
by copying the data into freshly allocated buffers; if there are none
left, the next frame is read.
This commit changes this: At the beginning of a frame, the palette is
read and cached as now. But audio frames are no longer cached at all;
they are returned immediately. This gets rid of copying and also allows
to remove the code for the buffer-to-AVStream correspondence.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The first four bytes of smacker audio are supposed to contain the number
of samples, so treat audio frames smaller than that as invalid.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When reading a new frame, the Smacker demuxer seeks to the next frame
position where it excepts the next frame; then it (potentially) reads
the palette, the audio packets associated with the frame and finally the
actual video frame. It is only at the end that the frame counter as well
as the position where the next frame is expected get updated.
This has a downside: If e.g. invalid data is encountered when reading
the palette, the demuxer returns immediately (with an error) and if the
caller calls av_read_frame again, the demuxer seeks to the position where
it already was, reads the very same palette data again and therefore will
return an error again. If the caller calls av_read_frame repeatedly
(say, until a packet is received or until EOF), this meight become an
infinite loop.
This could also happen if e.g. the size of one of the audio frames was
invalid or if the frame size was gigantic.
This commit changes this by skipping a frame if it turns out to be
invalid or an error happens otherwise. This ensures that EOF will be
returned eventually in the above scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Smacker demuxer buffers audio packets before it outputs them, but it
increments the counter of buffered packets prematurely: If allocating
the audio buffer fails, an error (most likely AVERROR(ENOMEM)) is returned.
If the caller decides to call av_read_frame() again, the next call will
take the codepath for returning already buffered audio packets and it
will fail (because the buffer that ought to be allocated isn't) without
decrementing the number of supposedly buffered audio packets (it doesn't
matter whether there would be enough memory available in subsequent calls).
Depending on the caller's behaviour this is potentially an infinite loop.
This commit fixes this by only incrementing the number of buffered audio
packets after having successfully read them and unconditionally reducing
said number when outputting one of them. It also changes the semantics
of the curstream variable: It is now the number of currently buffered
audio packets whereas it used to be the index of the last audio stream
to be read. (Index refers to the index in the array of buffers, not to
the stream index.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Don't need to do double check by the description of the API.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Saves initialization of an HEVCDecoderConfigurationRecord when
the data is already in ISOBMFF-format or if it is plainly invalid.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fix two cases of memleaks:
1. The leak of dv_demux
2. The leak of dv_fctx upon dv_demux allocate failure
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code for demuxing DV audio predates the introduction of refcounted
packets and when the latter was added, changes to the former were
forgotten. This meant that when avpriv_dv_produce_packet initialized the
packet containing the AVBufferRef, the AVBufferRef as well as the
underlying AVBuffer leaked; the actual packet data didn't leak: They
were directly freed, but not via their AVBuffer's free function.
https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2
contains samples for this (enable_drefs needs to be enabled for them).
Moreover, errors in avpriv_dv_produce_packet were ignored; this has been
changed, too.
Furthermore, in the hypothetical scenario that the track has a palette,
this would leak, too, so reorder the code so that the palette code
appears after the DV audio code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 8 * 9223372036854774783 cannot be represented in type 'long'
Fixes: 23381/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4818340509122560
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The segments / url can be modified by the io read when reloading
This may be an alternative or additional fix for Ticket8673
as a further alternative the reload stuff could be disabled during
probing
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also switch to using a pointer to access stream side data instead of
copying the stream's AVPacketSideData.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When doing streamed output, with e.g. +dash, if the mfra box ended
up being larger than the AVIOContext write buffer, the (unchecked)
seeking back to update the box size would silently fail and produce
an invalid mfra box.
This is similar to how other boxes are written in fragmented mode.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Nothing written in avformat_write_trailer() for the submuxers will be
output anyway because the AVIOContexts used for actual output have been
closed before the call. Writing the trailer of the subcontext has probably
only been done in order to free the memory allocated by the submuxer.
And this job has been taken over by the deinit functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1394614304 * 2 cannot be represented in type 'int'
Fixes: 23491/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5697377020411904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, ff_avc_decode_sps would parse a SPS and return some
properties from it in a freshly allocated structure. Yet said structure
is very small and completely internal to libavformat, so there is no
reason to use the heap for it. This commit therefore changes the
function to return an int and to modify a caller-provided structure.
This will also allow ff_avc_decode_sps to return better error codes in
the future.
It also fixes a memleak in mxfenc: If a packet contained multiple SPS,
only the SPS structure belonging to the last SPS would be freed, the
other ones would leak when the pointer is overwritten to point to the
new SPS structure. Of course, without allocations there are no leaks.
This is Coverity issue #1445194.
Furthermore, the SPS structure has been renamed from
H264SequenceParameterSet to H264SPS in order to avoid overlong lines.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After parsing the end timestamp of a WebVTT cue block, the current code
skips everything after the start of the timestamp that is not a \t, ' '
or \n and treats what is next as the start of a WebVTT cue settings list.
Yet if there is no such list, but a single \r, this will skip a part of
the cue payload (namely everything until the first occurence of \t, ' '
or \n) and treat what has not been skipped as the beginning of the
WebVTT cue settings list that extends until the next \r or \n (or the
end).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that AV1 only has exactly one sequence header, it is unnecessary
to copy the content of said sequence header into an intermediate dynamic
buffer; instead the sequence header can be copied from where it is in
the input buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1 - -9223372036854775808 cannot be represented in type 'long'
Fixes: 23490/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5133490093031424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Given that av_get_packet returns a blank packet on error, the only
difference to the current approach (that uses intermediate AVPackets on
the stack) is that st->attached_pic will be properly initialized on error
(i.e. the timestamps are AV_NOPTS_VALUE) whereas right now st->attached_pic
is only zeroed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Document that it also sets the size in case the desired side data is
absent (if the pointer has been supplied).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If stream's bitrate is not specified:
- for static manifest: an average bitrate will be calculated and used,
- for dynamic manifest: first segment's bitrate will be calculated and used, as before,
for bandwidth setting in adaptation sets.
dash demuxer get the stream info from sub-stream, but missed side
data/disposition part, e,g, missed the DOVI side data when the
stream is Dolby Vision streams
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
hls demuxer get the stream info from sub-stream, but missed side
data/disposition part, e,g, missed the DOVI side data when the
stream is Dolby Vision streams.
Reviewed-by <liuqi05@kuaishou.com>
Signed-off-by: vacingfang <vacingfang@tencent.com>
This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
General Requirements & Brands states:
* It SHALL have the av01 brand among the compatible brands array of the FileTypeBox
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Only read str_size bytes from offset 30 of extradata if the extradata is
indeed at least 30 + str_size bytes long.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
mov_read_custom tries to read three strings belonging to three different
tags. When an already encountered tag is encountered again, a new buffer
for the string to be read is allocated and stored in the pointer
destined for this particular tag. But in this scenario, said pointer
already holds the address of the string read earlier, leading to a leak.
This commit therefore aborts the reading process upon encountering
an already encountered tag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The argument pertaining to a printf %s conversion specifier must not
be NULL, even if the precision (i.e. the number of characters to write)
is zero. If it is NULL, it is undefined behaviour.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if allocating the AVStream for the subtitles fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or when creating extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon creating an AVStream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or when allocating extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or if creating the extradata failed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By default, a demuxer's read_close function is not called automatically
if an error happens when reading the header; instead it is up to the
demuxer to clean up after itself in this case. The mov demuxer did this
by calling its read_close function when it encountered some errors when
reading the header. Yet for other errors (mostly adding side-data to
streams) this has been forgotten, so that all the internal structures
of the demuxer leak.
This commit fixes this by making sure mov_read_close is called when
necessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.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>
In certain error scenarios, the underlying Matroska demuxer was not
properly closed, causing leaks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When demuxing a Matroska/WebM file, streams are added for tracks and for
attachments, so that the array containing the former can be NULL even
when the corresponding AVFormatContext has streams. So check for there
to be tracks in the MatroskaDemuxContext instead of just streams in the
AVFormatContext before dereferencing the pointer to the tracks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
matroska_parse_block currently asserts that the duration is not equal to
AV_NOPTS_VALUE, but there is nothing that actually guarantees this. It
is easy to create (spec-compliant) files which run into this assert;
so replace it and instead cap the duration to INT64_MAX, as the duration
field of an AVPacket is an int64_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
EBML binary elements are already made reference-counted when read;
so when populating the AVStream.attached_pic, one does not need to
allocate a new buffer for the data; instead the current code just
creates a new reference to the underlying AVBuffer. But this can be
improved even further: Just move the already existing reference.
This also fixes a memleak that happens upon error because
matroska_read_close has not been called in this scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
c801ab43c3 caused a regression: The stream
number is now parsed with strtoll without a fixed basis; as a
consequence, the "010" in a variant stream mapping like "a:010" is now
treated as an octal number (i.e. as eight, not ten). This was not
intended and may break some scripts, so this commit restores the old
behaviour.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: 22082/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5688619118624768
Fixes: crash from V-codecs/Theora/theora_testsuite_broken/multi2.ogg
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Suggested-by: Lynne on IRC
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created. Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to send a FEC packet erroneously (and so breaking out of the
retry loop).
This was resulting in incorrect FEC data being generated, and far too
many FEC packets to be sent (~100% FEC overhead).
fix#7863
Signed-off-by: David Holroyd <david.holroyd@m2amedia.tv>
Fixes: division by zero
Fixes: 23162/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4856420817436672
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
