A frame graph activation might not produce a frame in the requested sink, so
keep on requesting a frame there unless we encounter a filter activation with
buffersrc empty error.
This makes av_buffersink_get_frame(_flags) work according to its documentation
which claims that EAGAIN is only returned if additional frames must be inserted
into the graph.
Fate changes are because audio frames will have different sizes at segment
boundaries, but content is the same.
Signed-off-by: Marton Balint <cus@passwd.hu>
Sinks without an activate callback have no means to request frames in their
input, therefore the default activate callback should do it for them.
Fixes ticket #11624.
Fixes ticket #10988.
Fixes ticket #10990.
Signed-off-by: Marton Balint <cus@passwd.hu>
Even if all inputs are blocked an activate callback should request a frame on
some if its inputs if a frame is requested on any of its outputs.
Signed-off-by: Marton Balint <cus@passwd.hu>
EOF only need to be forwarded back if all outputs have reached EOF.
Fixes infinte loop with ffprobe -f lavfi -i "smptebars=d=1,select=n=2:e=1[out0][out1]"
Regression since d9e41ead82.
Fixes ticket #10959.
Fixes ticket #11366.
Signed-off-by: Marton Balint <cus@passwd.hu>
The status check is unneeded because an outlink with a nonzero status should
always return 0 for ff_outlink_frame_wanted(). Also use unsigned for index
because nb_outputs is unsigned as well.
Signed-off-by: Marton Balint <cus@passwd.hu>
In parse_cinespace(), memory allocated in in_prelut[] and out_prelut[]
would leak if allocate_3dlut() failed. Replace return ret with goto end
to free memory before return error code.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
After 3b26b782ee, `ebur128->true_peak` was only set to the maximum of the
current "true peak per frame" values, when it should report the true peak for
the entire stream.
Fixes: 3b26b782ee
The codecviewfilter, when used with qp=1, did not display quantization parameter values for H.264 streams because the QP table extraction was restricted to MPEG-2 video.
This patch enables H.264 support by updating ff_qp_table_extractto accept AV_VIDEO_ENC_PARAMS_H264. This allows for correct QP overlay on H.264 video
Signed-off-by: Timothee <timothee.informatique@regaud-chapuy.fr>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should prevent the possibility of audio data accumulating.
The commit also cleans up and simplifies the code a bit so all frame producers
(filter_frame(), flush_frame()) functions follow similar logic as
ff_inlink_consume_frame() for the return code.
Signed-off-by: Marton Balint <cus@passwd.hu>
Easier to read, less convoluted, and ~30% faster. Most importantly, this
avoids repeating the redundant recalculation of the true peak on every
single sample, by moving the FIND_PEAK() loop out of the main loop. (Note
that FIND_PEAK() does not depend on the current sample index at all, so
there is no reason for it to ever be recomputed here)
Processes two channels in parallel, using 128-bit XMM registers.
In theory, we could go up to YMM registers to process 4 channels, but this is
not a gain except for relatively high channel counts (e.g. 7.1), and also
complicates the sample load/store operations considerably.
I decided to only add an AVX variant, since the C code is not substantially
slower enough to justify a separate function just for ancient CPUs.
Instead of having a planar array for each channel, use a single packed array.
This will help processing multiple channels in parallel, as we can directly
load all channels' data in a single load instruction.
Also improves memory locality of data, as the loop order is:
for (samples) {
for (channels) {
process sample
}
}
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
