This filter uses ff_set_common_all_samplerates().
Also don't overwrite outlink->sample_rate in config_output;
it is harmless, because it is overwritten with the value it already
had, but it is an API violation.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This filter uses ff_set_common_all_samplerates().
Also don't overwrite outlink->sample_rate in config_output;
it is harmless, because it is overwritten with the value it already
had, but it is an API violation.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just like the sidechaingate filter, the sidechaincompress filter
overwrote the channel layout and channel count of its output in
its config_output callback to match the channel layout of its main
input instead of linking the main input and its output together
in its query_formats callback.
This is an API violation that can lead to segfaults, as in the
following filtergraph, where stereotools rightly expects stereo,
yet receives only mono:
[in]aformat=channel_layouts=mono,aformat=channel_layouts=stereo|mono[out];\
[out][in2]sidechaincompress,stereotools
Fix this by linking the channel layouts of the main input and the output
in query_formats and remove the code overwriting it in config_output.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sidechaingate filter wants its main input and its (only) output
to have the same channel layout and number of channels; yet it does
not link them in its query_formats callback. Instead it sets the
outlink to only accept the first offered choice for the main input's
channel layout and then sets both inputs to independently accept
any channel counts. The config_output callback then overwrote the
outlink's channel layout and channels properties with the main input's,
even though they may differ in case the first offered choice for
the main input's channel layout turns out not to be the final one.
Consider e.g. the following filtergraph:
[in]aformat=channel_layouts=mono,aformat=channel_layouts=stereo|mono[out];\
[out][in2]sidechaingate,stereotools
The two aformats ensure that the first offered channel layout (stereo)
will not be chosen for the input; yet it is the only offered channel
layout for the output of sidechaingate and will therefore be chosen
by the query_formats framework. Because the sidechaingate outputs
interleaved doubles which stereotools expects the output of
sidechaingate appears to be suitable as input for stereotools without
further conversions. Yet stereotools actually only receives a mono frame
and therefore overreads its input buffer which leads to segfaults;
it can also lead to heap corruption because there can be writes beyond
the end of the buffer, too.
Fix this by linking the channel layouts of the main input and the output
in query_formats and remove the code overwriting it in config_output.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The acrossfade filter uses the ff_set_common_* functions in its
query_formats(), so that the formats, the sample rates as well as
the channel layouts and counts of all links coincide.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The transpose, rotate, hflip, and vflip filters don't support them.
Fixes ticket #9432.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Almer <jamrial@gmail.com>
If no --cpu= option was passed to configure, we detect what the
compiler defaults to. This detected value was then fed back to the
rest of the configure logic, as if it was an explicit choice.
This breaks on Ubuntu 21.10 with GCC 11.1.
Since GCC 8, it's possible to add configure extra features via the
-march option, like e.g. -march=armv7-a+neon. If the -mfpu= option
is configured to default to 'auto', the fpu setting gets taken
from the -march option.
GCC 11.1 in Ubuntu seems to be configured to use -mfpu=auto. This
has the effect of breaking any compilation command that specifies
-march=armv7-a, because the driver implicitly also adds -mfloat-abi=hard,
and that combination results in this error:
cc1: error: ‘-mfloat-abi=hard’: selected processor lacks an FPU
One can compile successfully by passing e.g. -march=armv7-a+fp.
Therefore, restructure configure. If no specific preference was set
(and the 'cpu' configure variable was set as the output of
probe_arm_arch), the value we tried to set via -march= was the same
value that we just tried to detect as the compiler default.
So instead, just try to detect what the compiler defaults to, with
to allow setting other configure settings (such as 'fast_unaligned'),
but don't try to spell out the compiler's default via the -march flag.
Signed-off-by: Martin Storsjö <martin@martin.st>
Up until now, each call to avpriv_elbg_do() would result
in at least six allocations. And this function is called a lot:
A typical FATE run results in 52213653 calls to av_malloc; of these,
34974671 originate from av_malloc_array and from these 34783679
originate from avpriv_elbg_do; the msvideo1 encoder tests are behind
most of these.
This commit changes this by keeping the buffers and only reallocating
them when needed. E.g. for the encoding part of fate-vsynth1-msvideo1
total heap usage went down from 11,407,939 allocs and frees with
468,106,207 bytes allocated to 3,149 allocs and frees with 13,181,847
bytes allocated. The time for one encode2-call went down by 69%.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This affects all the arguments that don't change during a call
to avpriv_elbg_do(); doing so makes it easily recognizable which
arguments change upon recursive calls.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will be used in future commits to avoid having to allocate and free
all the buffers used.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is in line with our naming conventions for types.
Also change numCB to num_cb for the same reason.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The former name will be used for a context for avpriv_do_elbg().
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions are always called directly after another with
the exact same arguments. This avoids exporting a symbol;
it also avoids having to perform two calls for every caller.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will avoid a forward declaration later.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does the same as av_calloc(), so one of them should be removed.
Given that av_calloc() has the shorter name, it is retained.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
silk_lsp2poly()'s declaration contained arrays with array sizes;
yet these array sizes exceeded the number of actually accessed array
elements (which is related to another parameter) and this leads to
-Wstringop-overflow= warnings from GCC 11, because the arrays provided
by callers are only large enough for the actually used elements.
So replace the incorrect array sizes with comments containing
the correct array sizes. Given that these sizes are not compile-time
constants, they can only be communicated via a comment.
Reported by Paul B Mahol.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unused since 1f63665ca5.
Found-by: Soft Works <softworkz@hotmail.com>
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unnecessary since 1f63665ca5, because
the value the option is set to coincides with the default value.
Found-by: Soft Works <softworkz@hotmail.com>
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is supported only by a few decoders (h263, h263p, mpeg(1|2|)video
and mpeg4) and is entirely redundant with parsers. Furthermore, using
it leads to missing frames, as flushing the decoder at the end does not
work properly.
Co-authored-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSE2 is x86 specific, yet due to the call to av_get_cpu_flags()
compilers were unable to optimize the checks (and the call) away
on other arches.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case the current code tries to warn once; to do so, it uses
ordinary static ints to store whether the warning has already been
emitted. This is both a data race (and therefore undefined behaviour)
as well as a race condition, because it is really possible for multiple
threads to be the one thread to emit the warning. This is actually
common since the introduction of the new multithreaded scaling API.
This commit fixes this by using atomic integers for the state;
furthermore, these are not static anymore, but rather contained
in the user-facing SwsContext (i.e. the parent SwsContext in case
of slice-threading).
Given that these atomic variables are not intended for synchronization
at all (but only for atomicity, i.e. only to output the warning once),
the atomic operations use memory_order_relaxed.
This affected the nv12, nv21, yuv420, yuv420p10, yuv422, yuv422p10 and
yuv444 filter-overlay FATE-tests.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to associate log messages from slice contexts to
the user-visible SwsContext.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
And remove the unnecessary ffmpeg dependencies while at it.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: 38603/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSNSIREN_fuzzer-5741847809490944.fuzz
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: assertion failure
Fixes: 38332/clusterfuzz-testcase-minimized-ffmpeg_dem_DHAV_fuzzer-4522405595316224
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
By using preinit, the AVDCT already exists directly after
allocating the filter, so that the filter's AVClass's child_next
becomes usable for setting options with the AV_OPT_SEARCH_CHILDREN
search flag. This means that it is no longer necessary to use
the init_dict callback for this filter.
Furthermore, the earlier code did not abide by the documentation
of the init_dict callback at all: Instead of only returning the
options that have not been recognized it always returned all options
on any av_opt_set() error and errored out in this case, even if it
is just an unrecognized option. This behaviour has been inherited by
avfilter_init_dict(), contradicting its documentation. This is also
fixed in this commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
By using preinit, the SwrContext already exists directly after
allocating the filter, so that the filter's AVClass's child_next
becomes usable for setting options with the AV_OPT_SEARCH_CHILDREN
search flag. This means that it is no longer necessary to use
the init_dict callback for this filter.
Furthermore, the earlier code did not abide by the documentation
of the init_dict callback at all: Instead of only returning the
options that have not been recognized it always returned all options
on any av_opt_set() error and errored out in this case; yet if
the error was just caused by an unrecognized option, it should not
error out at all and instead return said option.
This behaviour has been inherited by avfilter_init_dict(),
contradicting its documentation. This is also fixed by this commit.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
