The Block timestamp read in matroska_parse_block() is in track timebase and is
passed on as such to the AVPacket which uses this timebase.
In the normal case the Cluster and Track timebases are the same because the
track->time_scale is 1.0. But when it is not the case, the values in Cluster
timebase need to be transformed in Track timebase so they can be added
together.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When the check was added (in 3668701f9600, in 2015), some IO
functions returned 0 on EOF (in particular, the TCP protocol
did, but the TLS protocol returned AVERROR_EOF). Since
0e1f771d22 in 2017, the TCP protocol also returns AVERROR_EOF
instead of 0, making the check for premature end never have the
intended effect.
Signed-off-by: Martin Storsjö <martin@martin.st>
mpegts_read_header stops parsing the file at the first PMT. However the check
that ensured this was wrong because streams can also be added before the first
PMT is received (e.g. EIT).
So let's make sure we are in the header reading phase by checking if ts->pkt is
unset instead of checking if the number of streams found so far is 0.
Signed-off-by: Marton Balint <cus@passwd.hu>
A variable has been assigned a value twice consecutively; essentially
the same happens when one performs av_init_packet on an AVPacket after
a call to av_packet_unref.
Found via PVS-Studio (see ticket #8156).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ASF specification of Metadata Objects' stream number is as follows:
"Specifies whether the entry applies to a specific digital media stream
or whether it applies to the whole file. A value of 0 in this field
indicates that it applies to the whole file; otherwise, the entry
applies only to the indicated stream number and must be between 1 and
127."
Yet the asf_o demuxer (the one originating from Libav) has always
treated such metadata as if it applied to a stream even though no stream
with a stream number may exist in a valid ASF file. This is fixed in
this commit; it affected e.g. the file
wma_with_metadata_library_object_tag_trimmed.wma from the FATE suite.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ASF file format has a limit of 127 streams and the "asf_o" demuxer
(the ASF demuxer from Libav) has an array of pointers for a structure
called ASFStream that is allocated on demand for every stream. Attached
pictures are not streams in the sense of the ASF specification, yet the
demuxer created an ASFStream for them; and in one codepath it also
forgot to check whether the array of ASFStreams is already full. The
result is a write beyond the end of the array and a segfault lateron.
Fixing this is easy: Don't create ASFStreams for attached picture
streams.
(Other results of the current state of affairs are unnecessary allocations
(of ASFStreams structures), the misparsing of valid files (there might not
be enough ASFStreams left for the valid streams if attached pictures take
up too many); furthermore, the ASFStreams created for attached pictures all
have the stream number 0, an invalid stream number (the valid range is
1-127). This means that invalid data (packets for a stream with stream
number 0) won't get rejected lateron.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The other branch already covers cases where enable_order_hint is true
and frame is of type Inter.
Regression since ddb0e4fecd
Fixes Coverity issues #1469194 and #1469195.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 64 * 33686018 cannot be represented in type 'int'
Fixes: 26911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-4904975073017856
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: NULL pointer dereference
Fixes: 26814/clusterfuzz-testcase-minimized-ffmpeg_dem_ICO_fuzzer-5758487797432320
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>
The spec in section 6.8.20 states the parameters should be loaded from a
reference frame indexed by film_grain_params_ref_idx.
Signed-off-by: James Almer <jamrial@gmail.com>
The previous threshold, 4 KB, maybe was reasonable when it was set
(in 2010), but in today's settings and with typical network speeds
and data sizes, it's pretty small. 32 KB probably is a more reasonable
default now, regardless of input.
This changes the test references for two seek tests.
When using the normal seek function, which boils down to the lseek(2)
function, a seek to an out of bounds position doesn't return an error,
but that condition is only reported when doing the subsequent read
(which returns EOF). When doing more seeks by fast forwarding, the
fact that the seeked to destination is out of bounds is noticed and
reported sooner in these cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
Michael Niedermayer
James Almer
Anton Khirnov
Steve Lhomme
Mark Reid
Martin Storsjö
Marton Balint
Limin Wang
Paul B Mahol
Gil Pedersen
Andrew Rodland
Andreas Rheinhardt
Carl Eugen Hoyos
Hendrik Leppkes
Timo Rothenpieler