Return the data in an AVFrame instead. This is what several users
({find,cover}_rect*) want anyway. This also avoids accessing
AVFrame.format (an int) via an enum AVPixelFormat*.
*: This commit actually avoids two frame copies For find_rect:
av_frame_clone() contained an implicit alloc+copy.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also rename it to ff_pixfmt_is_in(). This is more type-safe;
in particular, it is required to support -fshort-enum.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A constant named 8 has value 8 is redundant. These constants cannot
prevent user from setting other vaues. Just describe valid values
in the help message.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In config_output() for direction=DU/RL, the position
is initialized to s->sono_size, which equals h or w
when bar=0. That position is later used as an
in-bounds pixel coordinate without clamping in draw(),
causing writes past the end of the output planes.
Repro:
ffmpeg -f lavfi -i sine=frequency=1000:sample_rate=44100 \
-filter_complex "[0:a]showcwt=s=640x512:bar=0:direction=du[v]" \
-map "[v]" -frames:v 1 -f null -
AddressSanitizer: heap-buffer-overflow ... WRITE of size 1
Initialize and wrap the DU/RL position to sono_size - 1
(or 0 when empty), preventing out-of-bounds row/column
writes when bar=0 while preserving existing slide behavior.
Add chroma_location option so that, in the subsampled-to-subsampled case, the destination's chroma siting can be changed from the source's without having to use other filters. Useful, for example, when converting BT.2020 to BT.709, where the former customarily uses "top left" and the latter "left."
Update documentation.
Closes: #21185
The limiter_buf was being allocated with buf_size (3000ms worth of
samples) instead of limiter_buf_size (210ms worth of samples).
This resulted in allocating approximately 14x more memory than needed
for the limiter buffer. At 192kHz stereo:
- buf_size: 1,152,000 samples = 9.2 MB
- limiter_buf_size: 80,640 samples = 0.6 MB
- Wasted: ~8.2 MB per filter instance
The bug was introduced when the limiter buffer was added but the
wrong size variable was used in av_malloc_array().
This patch adds screen capture support via AMF vsrc_amf:
ffmpeg -y \
-filter_complex "vsrc_amf=framerate=120:capture_mode=keep_framerate" \
-c:v hevc_amf \
-frames:v 300 \
output_grab.mp4
If the HW frames pool is insufficient,
increase extra_hw_frames in filter_complex.
This avoids undefined behavior when -fshort-enums is enabled, where accessing enum arrays through int pointers causes incorrect memory reads.
Signed-off-by: niyinghao <niyinghao@xiaomi.com>
We use INT32_MIN/MAX so as to ensure we dont have to deal with 64bit width or height
on a int is int64 system. int64 width would overflow in a system where we assume the product of 2
values fit in int64
Fixes: #YWH-PGM40646-14
Found-by: An0n99X
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Update execute_model_th to support asynchronous execution by pushing tasks to the pending queue and notifying the worker thread.
Signed-off-by: Raja Rathour <imraja729@gmail.com>
Reviewed-by: Wenbin Chen <wenbin.chen@intel.com>
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
And free them once they are guaranteed to be no longer needed, instead of freeing them
when returned with an enhanced output.
Signed-off-by: James Almer <jamrial@gmail.com>
Implement NEON optimization for compute_weights_line.
Also update the function signature to use ptrdiff_t for stack arguments
(max_meaningful_diff, startx, endx). This is done to unify the stack
layout between Apple platforms (which pack 32-bit stack arguments tightly)
and the generic AAPCS64 ABI (which requires 8-byte stack slots for 32-bit
arguments). Using ptrdiff_t ensures 8-byte slots are used on all AArch64
platforms, avoiding ABI mismatches with the assembly implementation.
The x86 AVX2 prototype is updated to match the new signature.
Performance benchmark (AArch64) in MacOS M4:
./tests/checkasm/checkasm --test=vf_nlmeans --bench
compute_weights_line_c: 151.1 ( 1.00x)
compute_weights_line_neon: 62.6 ( 2.42x)
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The compiler was emitting a warning on every Cairo function replaced by
the `MOCK_FN_n` macros:
warning: 'cairo_...': redeclared without dllimport attribute after
being referenced with dll linkage
The macro `CAIRO_WIN32_STATIC_BUILD` prevents the attribute `dllimport` on
the declarations for these functions.
Signed-off-by: Ayose <ayosec@gmail.com>
To be able to reuse colors from the original frame, the last value returned by
`p()` is tracked in the eval state, and if it is assigned to a variable, the
original color components are copied to `color_vars`. Thus, commands like
`setcolor` and `colorstop` can use those variables:
setvar pixel (p(0, 0))
...
setcolor pixel
`fate-filter-drawvg-video` now also verifies the `p()` function.
Signed-off-by: Ayose <ayosec@gmail.com>
The arguments for `setvar` and `call` commands can be colors (like `#rrggbb`).
This replaces the previous trick of using `0xRRGGBBAA` values to use colors as
procedure arguments.
The parser stores colors as the value expected by Cairo (a `double[4]`). This
array is allocated on the heap so the size of the union in `VGSArgument` is
not increased (i.e. it is still 8 bytes, instead of 32).
Signed-off-by: Ayose <ayosec@gmail.com>
In libcairo, colors are defined as 4 separate components, and each one is double
between 0 and 1. Before this commit, colors stored in variables (like `defhsla`)
were converted to a `0xRRGGBBAA` value, which introduced some issues due to
rounding errors.
Now, when a color is assigned to a variable, the original values (a `double[4]`)
are stored in a dedicated array (`color_vars`), so no conversion is needed.
This change also reduces the cost of reading a color from a variable (no need
for `av_be2ne32`, or the `color[i] / 255` operations).
Signed-off-by: Ayose <ayosec@gmail.com>
