The spec specified indices in the order [x][y], but our code follows the
traditional C convention of [y][x]. This was not correctly account for
when calculating the base index of the grain database access.
The spec specifies x^31 + x^3 + 1 as the polynomial, but the diagram in
Figure 1-1 omits the +1 offset. The initial implementation was based on
the diagram, but this is wrong (produces subtly incorrect results).
It does not make much sense to me, but GCC somehow optimises the
inline assembler even though the output is very obviously used and
having observable side effects.
This reverts commit 09731fbfc3.
In this logical branch, fq->queued and fq->allocated must be equal.
Deleting this code will make it easier to understand the logic
(copy the data before tail to the newly requested space)
Signed-off-by: yangyalei <yangyalei@xiaomi.com>
ff_sbr_noise_table is only used by SBR DSP code
and sbrdsp.h is the header providing its declaration.
Furthermore, this ensures that checkasm does not pull
the whole AAC SBR and PS code in.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are not common.
Furthermore, this file is pulled in when linking checkasm and
up until now, the calls to ff_get_buffer() and av_codec_is_decoder()
caused all of libavcodec to be pulled in as well. Besides being
bad size-wise this also has the downside that it pulls in
avpriv_(cga|vga16)_font from libavutil which are marked as
being imported from another library when building libavcodec
as a DLL; this breaks checkasm because it links both lavc and lavu
statically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The part of said function that is common to both encoder and decoder
is negligible since c954cf1e1b766a0d1992d5be0a8be0055a8e1a6a
and more than offset by the costs of "Am I an encoder?" checks.
So move allocating the frames to the encoder and decoder directly.
Also rename ff_snow_frame_start() to ff_snow_frames_prepare(),
because a frame without a buffer has not been properly started.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is used by the AARCH64 code to filter a few
remaining lines in case the dimensions are not suitably
aligned; it is furthermore also used by checkasm to actually
test the AARCH64 code against. But it is normally not used
and this patch therefore moves it in bwdifdsp.h as a static
inline function so that it can be avoided if possible
or inlined where necessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise checkasm/vf_bwdif.c pulls in vf_bwdif.c and
then all of libavfilter. Besides being bad size-wise
this also has the downside that it pulls in
avpriv_(cga|vga16)_font from libavutil which are marked
as being imported from another library when building
libavfilter as a DLL and this breaks checkasm because
it links both lavfi and lavu statically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This already avoids unnecessary indirectly included headers
in the arch-specific vf_bwdif_init.c files; it is also in
preparation for splitting the actual functions out of vf_bwdif.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Dnn models has different data preprocess requirements. Scale and mean
parameters are added to preprocess input data.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Dnn models have different input layout (NCHW or NHWC), so a
"layout" option is added
Use openvino's API to do layout conversion for input data. Use swscale
to do layout conversion for output data as openvino doesn't have
similiar C API for output.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Applying film grain happens after ff_thread_finish_setup(),
so the parameters synced in hevc_update_thread_context() must not
be modified. But this is exactly what happens in case applying
film grain fails. (The likely result is that in case of frame threading
an uninitialized frame is output.)
Given that it is actually very easy to know in advance whether
ff_h274_apply_film_grain() supports a given set of parameters,
one can check for this before ff_thread_finish_setup()
and avoid allocating an unused buffer lateron.
Reviewed-by: Niklas Haas <ffmpeg@haasn.xyz>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: use after free
Fixes: 62153/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-4702814909366272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
From the documentation of GNU awk [1]:
"In most awk implementations, including gawk, rand() starts generating
numbers from the same starting number, or seed, each time you run awk.45
Thus, a program generates the same results each time you run it. The
numbers are random within one awk run but predictable from run to run.
This is convenient for debugging, but if you want a program to do
different things each time it is used, you must change the seed to a
value that is different in each run. To do this, use srand()."
This commit does exactly this.
[1]: https://www.gnu.org/software/gawk/manual/html_node/Numeric-Functions.html#index-rand_0028_0029-function
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead use float one by default for sample rate conversions.
The s16p internal transfer format produces visible and hearable
quantization artifacts.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
for S8 we continue to use S16 as it should have enough precision
Fate is adjusted so bitexactness is maintained between mips/arm/x86
if more tests became bit-inexact on some platform, the same change
can be done to them
The use of higher precision and float intermediates inevitably
leads to more differences between platforms.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
