Otherwise the context would be in an inconsistent state
if vp9_alloc_entries() failed (and if this would be checked).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We have more mutexes/condition variables whose initialization is
unchecked.
Also use a proper namespace for these functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also do not destroy and reinitialize mutexes and conditions when
certain input parameters change. Given that the decoder did not
create these variables at all during init, uninitialized mutexes
and conditions are destroyed before the very first initialization.
This is undefined behaviour and certain threading implementations
like pthreadGC2 crash when it is attempted.
Fix this by initializing these objects once during init and freeing
them in close.
Reported-by: Steve Lhomme <robux4@ycbcr.xyz>
Reviewed-by: Steve Lhomme <robux4@ycbcr.xyz>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
H.264 and H.265 levels' names are usually of the form "x" or "x.y"
with x and y being single digits; the one exception are the H.264 1b
levels. All of those levels' names fit into a char[4] and it is likely
that this future levels will do so, too.
Therefore this commit changes the H26(4|5)LevelDescriptor structures
to use such a char [4] instead of a pointer to a const char. This makes
the structures smaller (when sizeof(char*) == 8) and avoids relocations,
thereby moving the corresponding arrays from .data.rel.ro into .rodata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They were done in preparation for an upcoming 1.0 release.
Keep supporting previous releases for the time being.
Reviewed-by: BBB
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, ff_write_chained() copied the packet (manually, not with
av_packet_move_ref()) from a packet given to it to a stack packet whose
timing and stream_index is then modified before being sent to another
muxer via av_(interleaved_)write_frame(). Afterwards it is intended to
sync the fields of the packet relevant to freeing again; yet this only
encompasses buf, side_data and side_data_elems and not the newly added
opaque_ref. The other fields are not synced so that the returned packet
can have a size > 0 and data != NULL despite its buf being NULL (this
always happens in the interleaved codepath; before commit
fe251f77c8 it could also happen in the
noninterleaved one). This leads to double-frees if the interleaved
codepath is used and opaque_ref is set.
This commit therefore changes this by directly reusing the packet
instead of a spare packet. Given that av_write_frame() does not
change the packet given to it, one only needs to restore the timing
information to return it as it was; for the interleaved codepath
it is not possible to do likewise*, because av_interleaved_write_frame()
takes ownership of the packets given to it and returns blank packets.
But precisely because of this users of the interleaved codepath
have no legitimate expectation that their packet will be returned
unchanged. In line with av_interleaved_write_frame() ff_write_chained()
therefore returns blank packets when using the interleaved codepath.
Making the only user of said codepath compatible with this was trivial.
*: Unless one wanted to create a full new reference.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These were intended to pass options to auto-inserted avresample
resampling filters. Yet FFmpeg uses swresample for this purpose
(with its own AVDictionary swr_opts similar to resample_opts).
Therefore said options were not forwarded any more since commit
911417f0b34e611bf084319c5b5a4e4e630da940; moreover since commit
420cedd497 avresample options are
not even recognized and ignored any more. Yet there are still
remnants of all of this. This commit gets rid of them.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: Timeout
Fixes: 36875/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-4842960888922112
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Tested-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_pnm_parser and ff_vp3_parser already hit the current limit;
an addition to the former (to handle pfm) is planned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unlike libx264, libx265 does not handle the chroma format check
on its own side, so in order to not write out values which are
supposed to be ignored according to the specification, we limit
the writing out of chroma sample location to 4:2:0 only.
Fixes invalid reports of bad lossless crc.
While here make end of stream message into debug level as it is
not really important to user.
Also wait for new major sync frame as invalid concating of files
may produce invalid files, which cause various errors.
It is unnecessary and also ill-defined: av_malloc() returns a 1-byte
block of memory in this case, but this is not documented.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The chapters are independently allocated, so that comparing
the pointers is undefined behaviour. Furthermore, its result
is not platform-independent (and may not even be deterministic
on a particular platform). So compare the chapters' ids instead.
(avpriv_new_chapter() ensures that there are no duplicate ids.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This structure is only used for demuxers (mostly in
avformat_find_stream_info()), so only allocate it for them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has been allocated and initialized in avformat_find_stream_info()
until fd0368e7ca when the structure
was moved to AVStreamInternal and its allocation to avformat_new_stream.
In order to also initialize the struct for new streams that only get
created during avformat_find_stream_info() said the initialization has
been added to avformat_new_stream() later. Due to the Libav-FFmpeg split
this has been done twice: In 4cda8aa1c5
and in 30c26c2442. The initialization in
avformat_find_stream_info() has not been removed at all despite being
redundant. This commit removes it and the duplicated initialization in
avformat_new_stream().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The packet queue is already flushed in avformat_free_context() which
is called a few lines below.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An AVStream's internal AVCodecContext is pretty much unused for muxing:
The only place where any of its fields are set is
avformat_transfer_internal_stream_timing_info() where its time base is
set based upon the desired output format. The max_b_frames field is
never set at all, so don't read it in mux.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since 1c0885334d ff_compute_frame_duration
is only called from within utils.c and only for demuxers. So make it
static and remove the code in it that deals with muxers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVFormatContext.internal is already allocated by
avformat_alloc_context() on success; and on error,
avformat_alloc_context() cleans up manually without
avformat_free_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The WebM DASH Manifest demuxer creates a comma-delimited list of
all the timestamps of index entries. It allocates 20 bytes per
timestamp; yet the largest 64bit numbers have 20 decimal digits
(for int64_t it can be '-'+ 19 digits), so that one needs 21B
per entry because of the comma (resp. the final NUL).
The code uses snprintf, but snprintf returns the strlen of the string
that would have been written had the supplied buffer been big enough.
And if this is 21, then the next entry is written at an offset of 21
from the current position. So if enough such entries exist, the buffer
won't suffice.
This commit fixes this by replacing the allocation of buffer for
the supposedly worst-case with dynamic allocations by using an AVBPrint.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit b3a0548a98.
This breaks the usage of swscale options, scale_sws_opts should be
passed to auto-inserted scale-filters.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Fixes: signed integer overflow: 9223372034248226491 + 3275247799 cannot be represented in type 'long'
Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4538729166077952
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We introduced a ff_horiz_slice_avx2/512() implemented on a new algorithm.
In a nutshell, the new algorithm does three things, gathering data from
8/16 rows, blurring data, and scattering data back to the image buffer.
Here we used a customized transpose 8x8/16x16 to avoid the huge overhead
brought by gather and scatter instructions, which is dependent on the
temporary buffer called localbuf added newly.
Performance data:
ff_horiz_slice_avx2(old): 109.89
ff_horiz_slice_avx2(new): 666.67
ff_horiz_slice_avx512: 1000
Co-authored-by: Cheng Yanfei <yanfei.cheng@intel.com>
Co-authored-by: Jin Jun <jun.i.jin@intel.com>
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
The new vertical slice with AVX2/512 acceleration can significantly
improve the performance of Gaussian Filter 2D.
Performance data:
ff_verti_slice_c: 32.57
ff_verti_slice_avx2: 476.19
ff_verti_slice_avx512: 833.33
Co-authored-by: Cheng Yanfei <yanfei.cheng@intel.com>
Co-authored-by: Jin Jun <jun.i.jin@intel.com>
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
