Resizing is done on the RGB side: YUV to RGB conversion converts at the
visible input size before scaling, RGB to YUV conversion converts after
scaling at the output size. Every scaling pass then works on a single
packed plane and reuses the generic RGB kernels, and the conversion
kernels are reused with a float RGB side.
The RGB intermediates hold normalized floats, so filter overshoot and
out of gamut colors are not clipped before the scaler rounds and clamps
once. As conversion and filtering are linear, the result matches
scaling on the YUV side, apart from rounding and the chroma upsampling
of the conversion kernels.
Resizing during conversion always uses the generic filters with the
selected interp_algo, with nearest using point sampling weights.
Conversion without resizing keeps using the direct conversion kernels.
Assisted-By: Claude Opus 5.5
Each pass took its kernel, filter weights and planes from its position
in the chain, and the sample format parameters of its kernels from the
filter's input and output formats. Only the geometry came from the
buffers it reads and writes.
Describe every pass explicitly instead: its kernels, weights, written
plane groups, source and destination buffers, and the formats it reads
and writes. The fixed function and generic paths both build such a
plan, and processing a frame just runs its passes in order, passing
plane groups a pass does not write through from its source. This
makes adding passes that do not just read the input or write the
output, such as for color conversion, possible without special cases.
No functional change.
Assisted-By: Claude Opus 5.5
Only the yuv422 variants of the interleaved-to-planar converters were
tested, so the yuv420 variants had no coverage at all. The existing
helper works for 4:2:0 output as is, since it compares whole
destination buffers.
Also add single-line sizes covering the slow path, the fast path, and
the fast path with a tail, which would have caught the height-1 overrun
fixed in a previous commit.
Assisted-by: Claude Opus 5.5
The C and aarch64 implementations of uyvytoyuv420 and yuyvtoyuv420
average the chroma of each line pair with (a + b) >> 1, while the x86
SIMD loop uses pavgb, which computes (a + b + 1) >> 1. Its scalar tail
then truncated again, so x86 output mixed both.
Use round-to-nearest everywhere: in the C reference, the x86 scalar
tail, and on aarch64 by switching uhadd to urhadd and adding the
rounding bias in the scalar paths.
This changes the output of unscaled yuyv422/uyvy422 to yuv420p
conversion. No FATE test covers it.
Co-Authored-By: James Almer <jamrial@gmail.com>
Assisted-by: Claude Opus 5.5
For yuv420 output, interleaved_yuv_to_planar processes two source lines
per iteration and keeps the pair count, height >> 1, in w5. Both the
fast and the slow path test that counter only at the bottom of the loop,
so a height of 1 starts with w5 == 0: the body runs once, reading a
second source line and writing a second luma line that don't exist,
then w5 wraps to -1 and the loop runs far past the buffers.
A height of 1 is reached with 1-line frames, and also when swscale
slice-threads a conversion and the last slice is a single line.
Skip the pair loop when there are no full line pairs and go straight to
the existing odd-last-line handling. The fast-path tail code reads the
tail width from w9, which is otherwise only set at the loop head, so set
it there too.
uyvytoyuv422 and yuyvtoyuv422 do not pair lines and are not affected.
Fixes: #YWH-PGM45796-1
Reported-by: jpraveenrao
Assisted-by: Claude Opus 5.5
Limit the 8-bit column filter to the pixels remaining in the current slice. Pass slice_end - y at all three call sites so both the 8-bit and high-bit-depth column filters receive the correct remaining width. This handles partial 16-pixel blocks at frame and thread-slice boundaries. The non-column callbacks do not use this argument.
Fixes: #YWH-PGM40646-36
This reverts commit 59dd21047e.
The new tool does not properly resolve relative paths on MSYS2, and
potentially other targets.
It tries to make paths relative that are outside of the virtual MSYS
root dir, trying to .. below it. Resulting in invalid paths that send
MSYS make into an infinite loop somehow.
This reverts commit f3431169da, which
introduced various regressions and hangs with at least exr, as
reported by fate, and potentially other codecs that are not as
thouroughly tested.
Extend the internal CUDA frames context (CUDAFramesContext) to manage
block-linear CUarray surfaces alongside the existing pitched-linear
allocations.
When the frames context format is AV_PIX_FMT_CUARRAY, the caller
(e.g. NVDEC) can fill cuarray_desc and cuarray_num_surfaces before
calling av_hwframe_ctx_init(), which then allocates the CUarray
surfaces.
Also add cuda_transfer_data_from_cuarray() to support hwdownload
from CUarray frames to host memory via cuMemcpy2DAsync.
Co-authored-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Without setting this flag, apparently gnutls will only send the client
certificate according some logic based on what it thinks the server
accepts.
This is not the case a lot of times.
Just force it to send the client cert the user supplied, if one was
supplied, no matter what.
Fixes#22707
Not entirely sure if it should instead use some entirely different
approach here, given that images exceeding 2GB don't seem that crazy
to me, but so far processing such images results in a heap overflow,
since the size addition overflows and a much too small packet is
allocated and its size never checked again when writing into it.
Fixes #YWH-PGM40646-32
Depending on the threading backend the stdlib uses, creating a
mutex/condvar can be quite expensive.
So keep this object alive in the ctx, on which we synchronize via the
uninit mutex anyway.
Apparently, using a normal frame pool in a multithreaded environment
leads to strange resource leaks on shutdown, which vanish when using a
free threaded pool.
This was added in 4f78711f9c, with the
commit message claiming that it's a Microsoft restriction that array
textures with ArraySize > 2 cannot be created with
D3D11_BIND_RENDER_TARGET.
I was unable to find any documentation or other references on that, and
a quick test also found it to not be the case. So this patch removes
that restriction.
This enables frame sources, like the d3d11 capture filters, to output
frames in an array texture, which is neccesary to pass those frames as
input to some hardware encoders.
It was mistakenly removed in 0ce413af9c.
This matches how the Makefiles actually compile ObjC code, and
unlike C++, this seems to actually be benign and various existing
setups rely on that behaviour.
Combining C++ with our w32pthreads does not work out.
The C++ standard lib headers might include pthread.h, which will then
define clashing types with our w32pthread header.
To solve this, switch to using C++ native std::thread.
MinGWs ANSI stdio is quite slow, and when using UCRT, its extra features
are not needed.
The only troublesome part with ucrt printf is that is disagrees about
the size of "long double", but FFmpeg does not use that anywhere, let
alone prints it.
Right now, CFLAGS like -std=c17 leak onto the C++ compilers commandline,
leading to tons of warnings and even some errors.
Undefining __STRICT_ANSI__ causes strong warnings from the stdlib
headers. So only set it for C.
Using the built-in token seems to only partially work.
And in the latest Forgejo release the issue forcing the use of the
built-in token was fixed with:
https://codeberg.org/forgejo/forgejo/pulls/9025
Timo Rothenpieler