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>
Fixes: signed integer overflow: 2147483181 + 1024 cannot be represented in type 'int'
Fixes: 61117/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMIX_fuzzer-5387692433866752
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The PSNR filter uses the pixel values without considering
the color ranges. This is incorrect. Patch adds a warning
so at least the user knows it.
Let's see an example:
(1) Let's get a simple black pixel/white pixel image.
```
$ echo -n -e "\x00\x00\x00\xff\xff\xff" > /tmp/foo.rgb24
```
(2) From this image, let's distill full and limited range y4m
copies.
```
$ ffmpeg -y -f rawvideo -video_size 2x1 -pix_fmt rgb24 -i /tmp/foo.rgb24 -vf scale="out_range=full" -pix_fmt yuv420p /tmp/foo.full.y4m
$ xxd /tmp/foo.full.y4m
00000000: 5955 5634 4d50 4547 3220 5732 2048 3120 YUV4MPEG2 W2 H1
00000010: 4632 353a 3120 4970 2041 303a 3020 4334 F25:1 Ip A0:0 C4
00000020: 3230 6a70 6567 2058 5953 4353 533d 3432 20jpeg XYSCSS=42
00000030: 304a 5045 4720 5843 4f4c 4f52 5241 4e47 0JPEG XCOLORRANG
00000040: 453d 4655 4c4c 0a46 5241 4d45 0a00 ff80 E=FULL.FRAME....
00000050: 80 .
```
and
```
$ ffmpeg -y -f rawvideo -video_size 2x1 -pix_fmt rgb24 -i /tmp/foo.rgb24 -vf scale="out_range=limited" -pix_fmt yuv420p /tmp/foo.limited.y4m
$ xxd /tmp/foo.limited.y4m
00000000: 5955 5634 4d50 4547 3220 5732 2048 3120 YUV4MPEG2 W2 H1
00000010: 4632 353a 3120 4970 2041 303a 3020 4334 F25:1 Ip A0:0 C4
00000020: 3230 6a70 6567 2058 5953 4353 533d 3432 20jpeg XYSCSS=42
00000030: 304a 5045 4720 5843 4f4c 4f52 5241 4e47 0JPEG XCOLORRANG
00000040: 453d 4c49 4d49 5445 440a 4652 414d 450a E=LIMITED.FRAME.
00000050: 10eb 8080 ....
```
Note that the 2x images are the same (both have 1x pixel at the
darkest black, and one at the brightest white). Only difference
is the range.
(3) Let's calculate the PSNR score:
```
$ ./ffmpeg -filter_threads 1 -filter_complex_threads 1 -i /tmp/foo.full.y4m -i /tmp/foo.limited.y4m -lavfi "psnr" -f null -
...
[Parsed_psnr_0 @ 0x2f5dac0] PSNR y:22.972065 u:inf v:inf average:25.982365 min:25.982365 max:25.982365
```
As we are comparing an image with itself, we expect "y:inf" as the
luma PSNR. Issue here is that the PSNR filter just uses the pixel
values, ignoring the color ranges.
A possible solution would be to have the filter do the conversion.
Proposed solution is to add a warning.
```
$ ./ffmpeg -filter_threads 1 -filter_complex_threads 1 -i /tmp/foo.full.y4m -i /tmp/foo.limited.y4m -lavfi "psnr" -f null -
...
[Parsed_psnr_0 @ 0x2f5dac0] master and reference frames use different color ranges (pc != tv)
...
[Parsed_psnr_0 @ 0x2f5dac0] PSNR y:22.972065 u:inf v:inf average:25.982365 min:25.982365 max:25.982365
```
Tested:
Ran fate.
```
$ make fate -j
...
TEST seek-lavf-ppmpipe
TEST seek-lavf-pgmpipe
TEST seek-lavf-mxf_opatom
```
Fixes: signed integer overflow: 141394472 + 2038060365 cannot be represented in type 'int'
Fixes: 61787/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-5882604925878272
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: 1871429831 + 343006811 cannot be represented in type 'int'
Fixes: 61784/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AIC_fuzzer-5372151001120768
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
by making gain unsigned we have 1 bit more available
alternatively we can clip twice as in the g729 reference
Fixes: left shift of 23404 by 17 places cannot be represented in type 'int'
Fixes: 61728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ACELP_KELVIN_fuzzer-6280412547383296
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The comments to the function say that it does not implement the spec and
instead follows VTM.
This patch is quite likely not the right solution and more intended to show
the issue to people knowing the specific part of VTM ...
Fixes: signed integer overflow: 2147483392 + 256 cannot be represented in type 'int'
Fixes: 60505/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6216675924770816
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 60949/clusterfuzz-testcase-minimized-ffmpeg_dem_EVC_fuzzer-5959738853294080
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
