Those are private fields, no reason to have them exposed in a public
header. Since there are some (semi-)public fields located after these,
even though this section is supposed to be private, keep some dummy
padding there until the next major bump to preserve ABI compatibility.
Memory allocation for AVIOContext should be checked. In this code,
all error conditions are sent to the "goto error".
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 7958120835074169528 * 9 cannot be represented in type 'long long'
Fixes: 23382/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6230683226996736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code for GAB2 subtitles predates refcounting AVPackets. So in order
to transfer the ownership of a packet's data pkt->data was simply stored
and the packet zeroed; in the end (i.e. in the read_close-function) this
data was then simply freed with av_freep(). This of course leads to a leak
of an AVBufferRef and an AVBuffer. It has been fixed by keeping and
eventually unreferencing the packet's buf instead.
Additionally, the packet is now reset via av_packet_unref().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
An AVIStream (intended to be used as private data for an AVStream) would
leak in this scenario.
Also return a more fitting error code instead of AVERROR_INVALIDDATA.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If one uses a build without dv demuxer, an AVIStream struct that is
destined to be used as private data for an AVStream by the avi demuxer
would leak, because it has been moved from the AVStream (that is going
to be freed) and only stored in a local variable (in order to be used
for another AVStream), but if the dv demuxer is disabled, the earlier
code returned immediately instead.
Also return a better error code in this scenario (instead of
AVERROR_INVALIDDATA).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using ff_free_stream() makes the code more readable, more future-proof
(the old code freed AVCodecContexts and AVCodecParameters and its
substructures manually, so that there is a chance that there would be a
memleak for some time if new substructures were added) and reduces
code size.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long'
Fixes: Ticket8149
Found-by: Suhwan
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These functions already free it themselves before they allocate the new
extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is not uncommon to find code where the caller thinks to know better
what the return value should be than the callee. E.g. something like
"if (av_new_packet(pkt, size) < 0) return AVERROR(ENOMEM);". This commit
changes several instances of this to instead forward the actual error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
bswap.h was included since 7b114c09, yet since 3788a3c0 no explicit use
of anything from bswap.h has been made, so remove this header.
(Only AV_RL32 is used and while this might imply swapping on
big-endian systems, it is contained in libavutil/intreadwrite.h.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
free the value in error handling path to avoid the memory leak.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some security cams generate this, as well as some versions of VirtualDub and
VLC so support for _reading_ such files is justified.
Fixes ticket #7110.
See also this discussion: https://patchwork.ffmpeg.org/patch/8744/
Signed-off-by: Marton Balint <cus@passwd.hu>
AVCodecContext->bit_rate is int64_t since 7404f3bd
Unbreaks non-interleaved detection of v210 4k avi files, broken since 0eec40b7.
Reported-by: Xavier Càmara, Centre de Conservació i Restauració, Filmoteca de Catalunya
Fixes: signed integer overflow: 3775922176 * 4278190080 cannot be represented in type 'long'
Fixes: Chromium bug 791237
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This prevents part of one exploit leading to an information leak
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some muxers may use the BMP_HEADER Format Data size instead
of the ASF-specific one.
Bug-Id: 1020
CC: libav-stable@libav.org
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Fixes pts gaps when reading AVI files > 256GiB generated by FFmpeg.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is supposed to be a flag. The only currently defined value is
AVIO_SEEKABLE_NORMAL, but other ones may be added in the future.
However all the current lavf code treats this field as a bool (mainly
for historical reasons).
Change all those cases to properly check for AVIO_SEEKABLE_NORMAL.
This assert can with crafted files fail, a warning is already printed
for this case.
Fixes assertion failure
Fixes:1/assert.avi
Found-by: 连一汉 <lianyihan@360.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>