Fixes parsing of expressions like c0=c0+c0 or c0=c0|c0=c1. Previously no
error was thrown and for input channels, only the last gain factor was used,
for output channels the source channel gains were combined.
Signed-off-by: Marton Balint <cus@passwd.hu>
The output frame size is larger than the image containing a subsampled
plane - use the actual size of the image being written rather than the
dimensions of the intended output frame.
Reviewed-by: Dylan Fernando <dylanf123@gmail.com>
Behaves like the existing avgblur filter, except working on OpenCL
hardware frames. Takes exactly the same options.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
The intended target is OpenCL 1.2, so disable warnings for APIs deprecated
after that. This primarily applies to clCreateCommandQueue(), we can't use
the replacement clCreateCommandQueueWithProperties() because it was
introduced in OpenCL 2.0.
Also remove some unnecessary includes from overlay and program filters so
that the define is available at the right moment.
Add a new function to find the global work size given the output image and
the required block alignment, then use it in the overlay, program and unsharp
filters. Fixes the overlay and unsharp filters applying the kernel to
locations outside the frame when subsampled planes are present.
Since the config_props function now references both the input and output
links, rename the 'link' variable to 'outlink'.
Fix up some mismatching indentation.
Don't bother setting the width and height on the outlink; the filter
framework does that for us.
The old version of the filter had a problem where it would queue up
all of the duplicate frames required to fill a timestamp gap in a
single call to filter_frame. In problematic files - I've hit this in
webcam streams with large gaps due to network issues - this will queue
up a potentially huge number of frames. (I've seen it trigger the Linux
OOM-killer on particularly large pts gaps.)
This revised version of the filter using the activate callback will
generate at most 1 frame each time it is called.
This patch makes it possible to dinamically close the current segment
and step to the next one by introducing command handling capabilities
into the filter. This new feature is very usefull when working with
real-time sources or live streams as source. Combinig usage with zmqsend
tool you can interactively end the current segment and step to next one.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Right now, the PTS always starts out as 0, which causes problems on a
seek or when inserting this filter mid-stream.
Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first
frame instead if this is the case.
* commit 'b128be1748f3920a14a98307265df5f2d3433e1d':
vf_*_vaapi: Support increasing hardware frame pool size
Rewritten to apply to common VAAPI code rather than specific filters.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '6d86cef06ba36c0ed591e14a2382e9630059fc5d':
lavfi: Add support for increasing hardware frame pool sizes
Merged-by: Mark Thompson <sw@jkqxz.net>
These filters do not directly know whether the API they are using will
support dynamic frame pools, so this is somewhat tricky. If the user
sets extra_hw_frames, we assume that they are aware of the problem and
set a fixed size based on that. If not, most cases use dynamic sizing
just like they did previously. The hardware-reverse-mapping case for
hwmap previously had a large fixed size (64) here, primarily as a hack
for QSV use - this is removed and extra_hw_frames will need to be set
for QSV to work since it requires fixed-size pools (as the other cases
do, and which didn't work before).
Previously if ff_outlink_frame_wanted() returned 0 it could dereference a null pointer when trying to read nb_samples.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
comment about the looks like a duplicate line.
but that is used to reason x is expressed from y
Suggested-by: Paul B Mahol
Suggested-by: Michael Niedermayer
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This is done mainly in preparation for the SIMD patches.
- for the 8-bit input, decrease the blend factor precision to 7-bit.
- for the 16-bit input, increase the blend factor precision to 15-bit.
- make sure the blend functions are not called with 0 or maximum blending
factors, because we don't want the signed factor integers to overflow.
Fate test changes are due to different rounding.
Signed-off-by: Marton Balint <cus@passwd.hu>
