Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

This removes the use of the nonstandard combined structures, which
generated some warnings with clang and will cause alignment problems
with some parameter buffer types.

We perfer the coding style like:

/* some stuff */
if (error) {
    /* error handling */
    return -(errorcode);
}
/* normal actions */
do_something()
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

sws_freeContext have check the NULL pointer, so don't need to check
NULL before sws_freeContext.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Dump input pixel format in error message, it's will help to debugging
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Signed-off-by: Zhong Li <zhong.li@intel.com>

benchmarking with a simple command:
ffmpeg -i 1080p.mp4 -vf unsharp=la=3:ca=3 -an -f null /dev/null
with the patch, the fps increase from 50 to 120 on my local machine (i7-6770HQ).
Signed-off-by: Ruiling Song <ruiling.song@intel.com>

Used the command for 1080p h264 clip as follow:

a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null

after enabled the slice threading, the fps change from:

a). 144fps to 258fps (lutyuv)
b). 94fps  to 153fps (lutrgb)

in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Add slice threading support, use the command like:

./ffmpeg -i input -vf colorlevels -f null /dev/null

with 1080p h264 clip, the fps from 39 fps to 79 fps
in the local(Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Tries to find a device backed by the i915 kernel driver and loads the iHD
VAAPI driver to use with it.  This reduces confusion on machines with
multiple DRM devices and removes the surprising requirement to set the
LIBVA_DRIVER_NAME environment variable to use libmfx at all.

Opening the device via X11 (DRI2/DRI3) rather than opening a DRM render
node directly is only useful if you intend to use the legacy X11 interop
functions.  That's never true for the ffmpeg utility, and a library user
who does want this will likely provide their own display instance rather
than making a new one here.

For example: -init_hw_device vaapi:/dev/dri/renderD128,driver=foo

This may be more convenient that using the environment variable, and allows
loading different drivers for different devices in the same process.

Iterate over available render devices and pick the first one which looks
usable.  Adds an option to specify the name of the kernel driver associated
with the desired device, so that it is possible to select a specific type
of device in a multiple-device system without knowing the card numbering.

For example: -init_hw_device vaapi:,kernel_driver=amdgpu will select only
devices using the "amdgpu" driver (as used with recent AMD graphics cards).

Kernel driver selection requires libdrm to work.

Can be set to "drm" or "x11" to force a specific connection type.

The implementation will use some default in this case.  The empty string
is not a meaningful device for any existing hardware type, and indeed
OpenCL treats it identically to no device already to work around the lack
of this setting on the command line.

Cropping is not supported by VAAPI encode.

The "out_color_matrix" and "out_range" properties match the same options
in vf_scale; the others attempt to follow the same pattern.

Attempts to pick the set of supported colour properties best matching the
input.  Output is then set with the same values, except for the colour
matrix which may change when converting between RGB and YUV.

Parameter buffer creation can fail.

Also enables cropping on all VAAPI filters, inherited from the existing
support in scale_vaapi.

Set the cropping fields in the AVFrame.

And fix typo of the 1833 of hlsenc.c
Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
Signed-off-by: Steven Liu <lq@onvideo.cn>

Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Improves: Timeout (355sec -> 97sec)
Improves: 14709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5704215281795072
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg

This is based on target_dec_fuzzer
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes two warnings:
libavfilter/avf_showspatial.c:157:26: warning: variable ‘w’ set but not used
libavfilter/avf_showspatial.c:157:23: warning: variable ‘h’ set but not used

Additionally:
- Renamed TIFF_WHITE_LEVEL to DNG_WHITE_LEVEL since it is specified
  in the DNG spec.
- Added/changed some comments to be more precise in differentiating
  between TIFF, TIFF/EP and DNG values.

Related to ticket: https://trac.ffmpeg.org/ticket/4364Signed-off-by: Nick Renieris <velocityra@gmail.com>

SubIFDs that were part of more than single-sized "SubIFDs" tags were
being ignored due to existing code ignoring that case.

This patch makes is so the first entry is read, which is not ideal
but enough for some DNG images present in the wild to be decodeable
More specifically, the first SubIFD which we would process with this
patch is the main image and the second one is a second thumbnail,
which is not as important to decode.

In DNG images with the .tiff extension, it solves the issue where
the TIFF thumbnail in IFD 0 was incorrectly parsed (related
confusion: [1]).

Embedded thumbnails for DNG images can still be decoded with the
"-thumbnail" option.

Related to ticket: https://trac.ffmpeg.org/ticket/4364

[1]: https://superuser.com/questions/546879/creating-video-from-dng-images-with-ffmpegSigned-off-by: Nick Renieris <velocityra@gmail.com>