This was requested by users of `vf_libplacebo`, to mirror the existing
option on the other `vf_scale_*` family of filters. While we have
`vf_normalize`, it was not as useful in the event that the content
stretching was actually desired.
Bridges an important usability gap between `vf_scale` and `vf_libplacebo`
that made mixing and matching the filters needlessly difficult.
This aligns the behavior of vf_libplacebo with other filters in the
vf_scale family, that forward any change in the SAR as a result of
changing the output resolution to the output frame / link, and updates
the ff_scale_adjust_dimensions() call to continue working as intended.
The new behavior reflects the documentation of vf_libplacebo, which
described this behavior despite that not being the way the filter worked
up to this point.
As an aside, also fixes a bug where the AVFrame SAR was inconsistent
with the AVFilterLink SAR when the s->nb_inputs > 1 condition was met.
Under normal circumstances, this change does not affect anything, as the vast
majority of filters either support only vulkan or only software formats.
However, when a filter supports both (such as vf_libplacebo itself, and
possibly vf_scale in the future), linking together two such filter instances
without an explicit format will default matching the input format, resulting
in a redundant round trip through host RAM.
This change bumps up AV_PIX_FMT_VULKAN to the first entry in the format list,
ensuring that it gets preferred whenever possible.
When chroma subsampling is in use, the filter averages
the corresponding (non subsampled) alpha values to get
the actual alpha value. When vertical subsampling is
in use, the next line is accessed via a[src->linesize[3]],
yet a is an uint16_t* for >8 bit formats and linesize
is always in bytes, so that this actually uses the second
line below the current one. This is fixed in this commit.
No FATE test needed updates, because the filter-overlay-yuv420p10
and filter-overlay-yuv444p10 tests use a yuv420p test file
that has constant opacity after conversion to yuva.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just keep the pointers for the beginning of a line uint8_t*
and use uint16_t* to do the actual processing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This happens when the pixel format of the output does not
have an alpha channel. It leads to FATE failures with
the ffmpeg-filter_colorkey, filter-overlay-dvdsub-2397
filter-overlay,
filter-overlay_{gbrp_gbrap,nv12,nv21,yuv420,yuv420_yuva420,
yuv420p10,yuv422_yuva422,yuv422p10,yuv444_yuva444,yuv444p10}
and sub2video tests when using Clang UBSan.
Fix this by only performing the pointer arithmetic when
it is going to be used. This can be checked via variables
that compile-time constants due to inlining, so that the
checks are free. Given that the pointer is potentially
used as a function argument, the compiler could elide
the calculation, but not it can. The size of .text decreased
by 1632B with GCC 14 and by 1392B with Clang 19 (both -O3).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This otherwise generates an inconsistency between the frame state and the
link state, since the link state is set to 1:1 explicitly when `reset_sar`
is enabled, but this line of code unconditionally overwrote the output
frame SAR with the value that would be computed in the absence of `reset_sar`.
cf. vf_scale_cuda, which does this correctly
The MMX requantize functions have the MMX permutation
(i.e. FF_IDCT_PERM_SIMPLE) hardcoded and therefore
check for the used permutation (namely via a CRC).
Yet this is very ugly and could even lead to misdetection;
furthermore, since d7246ea9f2
the permutation used here is de-facto and since
bfb28b5ce8 definitely
impossible on x64, making this code dead on x64.
So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Check the alpha plane for (almost) transparent frames, instead of checking
the luma channel for almost black frames.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
Flipping can already be accomplished by setting the crop_w/h expressions to
their negative values, so together these options can implement any of the
common frame orientations.
ol->frame_rate is 0/0, so we need to calcalute the correct value based on
the il->frame_rate instead. Also adjust the time base, PTS and frame_duration
values accordingly. (Logic taken from vf_tinterlace.c)
Fix chroma_location being cleared by setrange and setfield filters.
This was forgotten in 201f1cba15.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
While technically not specifiad as valid by the AVFilterLink documentation,
it is currently possible to get an FPS of zero from various sources inside
libavfilter (notably vf_buffersrc).
Avoid a division by zero and resulting infinity when this happens.
