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
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>
