The unsharp filter uses an array of arrays of uint32_t, each of which is
separately allocated. These arrays also need to freed separately; but
before doing so, one needs to check whether the array of arrays has
actually been allocated, otherwise one would dereference a NULL pointer.
This fixes #8408.

Furthermore, the array of arrays needs to be zero-initialized so that
no uninitialized pointer will be freed in case an allocation of one of
the individual arrays fails.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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>

This was added in early 2013 and abandoned several months later; as far as
I can tell, there are no external users.  Future OpenCL use will be via
hwcontext, which requires neither special OpenCL-only API nor global state
in libavutil.

All internal users are also deleted - this is just the unsharp filter
(replaced by unsharp_opencl, which is more flexible) and the deshake filter
(no replacement).

Fixes memleak
Fixes part of CID1197065

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Anything bigger is not supported anyway.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Otherwise filter would happily give overflows and produce useless output.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Libav, for some reason, merged this as a public API function. This will
aid in future merges.

A define is left for backwards compat, just in case some person
used it, since it is in a public header.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

With the introduction of AVFilterContext->is_disabled, we can simplify
the custom passthrough mode in filters.

This commit is technically a small compat break, but the timeline was
introduced very recently.

Doxy by Stefano Sabatini.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Flag added in a few simple filters. A bunch of other filters can likely
use the feature as well.

Conflicts:

	libavfilter/avfilter.c
	libavfilter/vf_drawtext.c
	libavfilter/vf_lut.c
	libavfilter/vf_select.c
	libavfilter/vf_setpts.c
	libavfilter/vsrc_color.c
	libavfilter/vsrc_movie.c

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Deprecate AVFilterBuffer/AVFilterBufferRef and everything related to it
and use AVFrame instead.

Increase performance, to match mp=unsharp.

Also update the documentation accordingly, and suggest a meaningful range.

In particular, avoid out-of-buffer access and crashes with too big
values, and rework documentation accordingly.

Remove possibly pointless inconsistency with the ported code.

Also specify parameter value ranges consistent with those of the ported
filter.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Any alleged performance benefits gained from the split are purely
mythological and do not justify added code complexity.

A number of compilers, for example those from TI and IBM, choke on
these initialisers.  The current style is also quite ugly.

Signed-off-by: Mans Rullgard <mans@mansr.com>

This reduces code duplication and prevents stale pointers from remaining
on the link.

This reduces code duplication and prevents stale pointers from remaining
on the link.

It is not used in any filters currently and is inherently evil. If
passing binary data to filters is required in the future, it should be
done with some AVOptions-based system.