When allocating the MJpegContext fails (or if the dimensions run afoul
of the 65500x65500 limit), an attempt to free a subbuffer of said
context leads to a segfault in ff_mjpeg_encode_close().
Seems to be a regression since 467d9e27e0.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case it also fixes a potential for compilation failures:
Not all compilers can handle the case in which a function with
a forward declaration declared with an attribute to always inline it
is called before the function body appears. E.g. GCC 4.2.1 on OS X 10.6
doesn't like it.
Reviewed-by: Pavel Koshevoy <pkoshevoy@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some old DV AVI files have the DSF-Flag of frames set to 0, although it
is PAL (maybe rendered with an old Ulead Media Studio Pro) ... this causes
ffmpeg/VLC-player to produce/play corrupted video (other players/editors
like VirtualDub work fine).
Fixes ticket #8333 and replaces/extends hack for ticket #2177
Signed-off-by: Marton Balint <cus@passwd.hu>
A PutBitContext has a field called size_in_bits which is set to the
context's bitsize init_put_bits(); but it isn't used at all (the PutBits
API uses pointers directly and not bit indexes), so remove it (due to
ABI concerns the actual element is only removed at the next bump).
Furthermore, the multiplication inherent in setting this field can lead
to undefined integer overflows. This is particularly true for FFV1,
which uses a very big worst-case buffer (37*4*width*height; even
ordinary 1080p triggers an overflow). Ticket #8350 is about this
overflow which this commit fixes.
This means that the effective range of the PutBits API is no longer
restricted by the /8 as long as one isn't using put_bits_(count|left).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The function to write an ordinary (luma or chroma) plane as well as
the function for writing an alpha plane have some similarities:
They record the initial bitposition (despite said position always being
byte-aligned), flush the PutBitContext themselves and return the amount
of bytes they wrote.
This commit factors this out; it also replaces bitpositions by
bytepositions and it avoids recording the initial byteposition because
said information is already available from the position at the end of
the last plane.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Despite write_huff_codes() receiving an ordinary buffer (not a
PutBitContext), it returned the amount of data written in bits,
not in bytes. This has been changed: There is now no intermediate
bitcount any more.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several encoders used code like the following to check for the amount of
bytes left in a PutBitContext:
pb->buf_end - pb->buf - (put_bits_count(pb) >> 3)
Besides the fact that using the pointers directly might pose
a maintainence burden in the future this also leads to suboptimal code:
The above code reads all three pointers (buf, buf_ptr and buf_end), but
touching buf is unnecessary and switching to put_bytes_left()
automatically fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Often a caller doesn't want the amount of bits written via a
PutBitContext, but the amount of bytes. This in particular happens
after one has flushed the PutBitContext (e.g. at the end of encoding,
when one wants to know the actual packet size). The current way of doing
this is with put_bits_count(pb)/8 (or (put_bits_count(pb) + 7)/8).
Yet this has some issues: It contains implicit multiplications and
divisions by 8 with a cast in between; it obscurs the intent; and
it restricts the size of the buffer to (currently) INT_MAX/8 (or
to 1/8 of the maximum of whatever put_bits_count() returns), although
said restriction is not really necessary for users that don't need
a bitcount.
Corresponding functions for the amount of bytes left have also been
addded.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The PutBits API checks the available space before every write,
so this check for overread is dead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
We are already word-aligned here, so one can just as well flush the main
PutBitContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Compilation would fail if it were outcommented as it refers to a
nonexistent PutBitContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: Division by 0
Fixes: 30952/clusterfuzz-testcase-minimized-ffmpeg_BSF_SETTS_fuzzer-6601016202100736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids crafted files from consuming excessive resources recomputing the clut after each pixel change
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -2147471366 - 18638 cannot be represented in type 'int'
Fixes: 30157/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5171199746506752
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The user buffers passed to avcodec_encode_video2() haven't been propagated to
AVCodec.encode2 implementations since 93016f5d1d.
Also, the generic encode code already unrefs the packet if nothing was encoded.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array access
Fixes: 31640/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5630883286614016
Fixes: 31619/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5176667708456960
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: 2314885530818453536 - -9070214327174160352 cannot be represented in type 'long'
Fixes: 31000/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-6558389742206976
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>
Up until now, initializing the mutexes/condition variables wasn't
checked by ff_frame_thread_init(). This commit changes this.
Given that it is not documented to be save to destroy a zeroed but
otherwise uninitialized mutex/condition variable, one has to choose
between two approaches: Either one duplicates the code to free them
in ff_frame_thread_init() in case of errors or one records which have
been successfully initialized. This commit takes the latter approach:
For each of the two structures with mutexes/condition variables
an array containing the offsets of the members to initialize is added.
Said array is used both for initializing and freeing and the only thing
that needs to be recorded is how many of these have been successfully
initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In case an error happened when setting up the child threads,
ff_frame_thread_init() would up until now call ff_frame_thread_free()
to clean up all threads set up so far, including the current, not
properly initialized one.
But a half-allocated context needs special handling which
ff_frame_thread_frame_free() doesn't provide.
Notably, if allocating the AVCodecInternal, the codec's private data
or setting the options fails, the codec's close function will be
called (if there is one); it will also be called if the codec's init
function fails, regardless of whether the FF_CODEC_CAP_INIT_CLEANUP
is set. This is not supported by all codecs; in ticket #9099 it led
to a crash.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 003b5c800f introduced seeking in argo_asf,
but this was missed, leading to non-deterministic output.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reduces codesize because the offset in pointer+offset addressing
requires less bytes to encode. Reduces the size of .text from 8871B
to 8146B (GCC 10, -O3, x64).
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the VC-1 decoders allocated an AVFrame for usage with
sprites during vc1_decode_init(); yet said AVFrame can be freed if
(re)initializing the context (which happens ordinarily during decoding)
fails. The AVFrame does not get allocated again lateron in this case,
leading to segfaults.
Fix this by moving the allocation of said frame immediately before it is
used (this also means that said frame won't be allocated at all any more
in case of a regular (i.e. non-image) stream).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It automatically records the current length of the string,
whereas the current code contains lots of instances of
snprintf(buf + strlen(buf), buf_size - strlen(buf), ...).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If the numerical constants for colorspace, transfer characteristics
and color primaries coincide, the current code presumes the
corresponding names to be identical and prints only one of them obtained
via av_get_colorspace_name(). There are two issues with this: The first
is that the underlying assumption is wrong: The names only coincide in
the 0-7 range, they differ for more recent additions. The second is that
av_get_colorspace_name() is outdated itself; it has not been updated
with the names of the newly defined colorspaces.
Fix both of this by using the names from
av_color_(space|primaries|transfer)_name() and comparing them via
strcmp; don't use av_get_colorspace_name() at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Our "get name" functions can return NULL for invalid/unknown
arguments. So check for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The SVQ3 decoder modifies the input bitstream at two places.
One of them is only reached when the file is watermarked.
Therefore commit 2264c11081
made a copy of all the frame data in this case.
But there is a second possibility for modifying the frame and
therefore Libav commit 1098f5c049
made the decoder always copy the data. This of course makes
the additional copy for watermarked frames redundant, but it hasn't
been removed. This commit does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It takes care of zeroing padding (which has been forgotten here).
Also rename the size variable to indicate that this is not the size
of the current slice.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Because the properties of frames returned from ff_get/reget_buffer
are not reset at all, lots of returned frames had palette_has_changed
wrongly set to 1. This has been changed, too.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When flushing, the parser receives a dummy buffer with padding
that lives on the stack of av_parser_parse2(). Certain parsers
(e.g. Dolby E) only analyze the input, but don't repack it. When
flushing, such parsers return a pointer to the stack buffer and
a size of 0. And this is also what av_parser_parse2() returns.
Fix this by always resetting poutbuf in case poutbuf_size is zero.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Added in dc51a72ba4, yet even back then
the check was always true as the AVCodecContext has already been memset
to zero before that.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
