The cuda hwcontext has listed AV_PIX_FMT_VULKAN among its supported
formats since Vulkan interop was first added, so a device's frame
constraints advertise Vulkan as a transfer-compatible ("sw") format.
This is what allows an hwupload targeting a cuda device to accept a
Vulkan frame as input during format negotiation.
The Vulkan hwcontext never made the reciprocal declaration, so an
hwupload targeting a Vulkan device would not accept a cuda frame, and a
cuda -> Vulkan upload could not be configured even though the transfer
itself is supported. Advertise AV_PIX_FMT_CUDA in the Vulkan frame
constraints to ensure we have consistent behaviour in both directions.
(cherry picked from commit d09d5afc3a)
GetPhysicalDeviceImageFormatProperties2() must be queried with the format
that will actually be used to create the image, otherwise the external
memory export capability check answers for a different format than the one
being allocated.
When AV_VK_FRAME_FLAG_DISABLE_MULTIPLANE is set (e.g. by ffplay for CUDA
interop), vulkan_frames_init selects the per-plane fallback format via
vkfmt_from_pixfmt2(disable_multiplane=1) and stores it in hwctx->format[].
The image is then created with that fallback format. Querying the
multiplane vkf instead returns capability for a format that is never
instantiated, and on NVIDIA GPUs with OPTIMAL tiling the answer differs
between the two formats, producing broken CUDA hwaccel output.
Read hwctx->format[0], which is populated by vulkan_frames_init before
vulkan_pool_alloc runs, so the query matches the image regardless of
whether the multiplane or fallback path was taken.
Fix artifacts with `ffplay -hwaccel cuda foo.mp4`.
(cherry picked from commit 0baa71b53c)
Cuda currently only supports packed and single-component planar formats, but
fails to import semi-planer (eg: NV12, P010). Even though there are now
semi-planar cuda array formats, which the latest nvdec can use, these formats
are not used when mapping Vulkan imports. Maybe they'll fix that some day.
But until then, let's explicitly detect the case and return a clear error
message for the user.
Exercising this error path revealed that vulkan_free_internal() frees
f->internal on a transfer error and then runs again when the frame is
destroyed, dereferencing the freed pointer; let's make it idempotent.
(cherry picked from commit c29d710cd5)
The current semaphore logic dates back to a time where we did not have any
multiplane images, and it has not kept up. As a result, we currently try and
manipulate too many semaphores when dealing with multiplane images, leading to
errors and crashes. Let's fix it.
(cherry picked from commit 30ba440386)
The current export_to_cuda logic only works for planar and semi-planar formats.
When presented with a single plane packed format, it will incorrectly
calculate the number of channels, resulting in failures later on when cuda
code tries to access the frame. Let's fix it.
(cherry picked from commit 927f205eb8)
Odd-height yuv420p result in incorrect calculations of the U-plane
address offset. The last row of the V-plane overlapped with and was
overwritten by the first row of the U-plane, leading to chroma artifacts.
```
ffmpeg -init_hw_device cuda=cu -filter_hw_device cu -f lavfi -i \
testsrc=s=1920x1081,format=yuv420p -vf hwupload -c:v hevc_nvenc \
-vframes 1 -y <OUTPUT>
```
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
(cherry picked from commit 3f6bf150cb)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
This is needed by the ops code, to represent intermediate values for 32-bit
formats, which can exceed the value range of int32_t (especially for
intermediate products).
I copied the math almost 1:1 from rational.c, but adapted to use the 128-bit
integer wrappers defined by int128.h. I added a generous amount of tests in
any case.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Passing -INT_MIN to av_sub_q() overflows due to the negation. Writing out
the formula explicitly avoids this.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The existing tests don't really stress test the edge-case behavior when adding
or multiplying values that over/underflow.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
These can be implemented efficiently on most modern 64-bit compilers. Fallback
is only needed for 32-bit, which we do using the existing generic "integer.h"
header (currently also hard-coded as 128 bits).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
NVDEC and CUVID decode 12-bit 4:2:0 content to AV_PIX_FMT_P012 and
12-bit 4:2:2 to AV_PIX_FMT_P212, but these formats were missing from
the CUDA frames context supported format list. As a result
av_hwframe_ctx_init() rejected them ("Pixel format not supported",
AVERROR(ENOSYS)), so decoding 12-bit content to CUDA frames and
hwdownload of such frames both failed.
Add P012 and P212 next to the existing P010/P016 and P210/P216 entries.
The per-plane device transfer is derived generically from the pixel
descriptor, so no other changes are required.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
The seven *_from_name() functions in pixdesc.c (color_range,
color_primaries, color_transfer, color_space, chroma_location,
alpha_mode) used av_strstart() for prefix matching, which returns
incorrect results when one name is a prefix of another.
av_color_space_from_name("ycgco-re") matched "ycgco" at index
AVCOL_SPC_YCGCO and returned 8 instead of AVCOL_SPC_YCGCO_RE.
av_color_space_from_name("ycgco-ro") had the same issue. The
*_ext name lookups inside av_color_primaries_from_name and
av_color_transfer_from_name had the same flaw.
Switch all eight call sites from av_strstart() to strcmp() for
exact matching. No in-tree callers rely on prefix matching.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
This fallback function is used if external MMX is available,
while inline MMX and intrinsics for emitting emms are unavailable.
It is implemented as an avpriv function, which has several
drawbacks for shared builds:
1. The function is so small (3 bytes; 16 with padding)
that the overhead of exporting and importing it dwarfs
the gains from code deduplication.
2. A call to an external library has more overhead than
a library-internal one.
3. It may cause linking failures when a libavutil not exporting
avpriv_emms_asm() is paired with a library needing it
(if inline assembly and intrinsics were unavailable when building
the dependent library). I am not aware of this ever happening.
4. We would be forced to keep avpriv_emms_asm() around for ABI stability
even after it is no longer needed.
This commit therefore uses the STLIBOBJS, SHLIBOBJS approach
to duplicating it into each library on its own if needed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Commit c6c8063186 added getters for them.
Also remove av_export_avutil and the BUILDING_foo macro.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Map DXGI_FORMAT_P016 to AV_PIX_FMT_P016 and keep the 12-bit P012 as a
compatibility entry, matching how Y216 and Y416 already expose both their
native 16-bit and 12-bit variants.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
LLVM commit
0d471b3f64
made Clang save and restore EBP around inline asm that only
clobbers it. This can make the existing EBP crash probe pass even
when the compiler still cannot allocate the 7-register i386 inline
asm used behind HAVE_7REGS.
Keep ebp_available for HAVE_6REGS and add a separate
x86_32_7regs probe for HAVE_7REGS.
Discussion:
https://marc.info/?t=178015389900001&r=1&w=2
This avoids reg-reg moves and saves 90112B of .text here.
It also makes the code less reliant on a clean upper ymm state.
Not all functions use VEX encoding yet; besides inline assembly
functions which are not influenced by x86inc.asm there are also
functions using a mixture of xmm and mmx registers (e.g.
h264_intrapred.asm) using INIT_MMX where the automatic VEX translation
is not active. This means that some parts of the code still rely
on a clean upper ymm state.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several _alloc() functions taking a size_t *size output parameter
either left it uninitialized or unconditionally set it to sizeof(...)
when the underlying av_mallocz() failed. Callers that check the
returned pointer first are unaffected, but the stale value is a trap
for any code path that inspects size without a NULL check.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The leading sign of a (sub)expression is stored as +-1 in each node's
value field (parse_factor) and every other function multiplies its
result by it. print, squish, gauss and lerp ignored it, so e.g.
-print(1) evaluated to 1 instead of -1 and -gauss(0) to 0.398942
instead of -0.398942, while -1*print(1) was correct.
Fixes: ticket #9833
Reported-by: Player701
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
Before, glibc appears to transitively pull in the syscall number
definitions, but musl does not do this. Thus, `__NR_riscv_hwprobe`
is undeclared and an error is emitted.
Fix this by including `<asm/unistd.h>`, which makes the macro
visible on musl.
The AVX2 15xM PFA FFT calls its second-dimension subtransform with dirty
YMM. That subtransform may be a legacy-SSE codelet (fft4 is SSE2 only),
causing AVX<->SSE transition penalties. Clear them after the first
dimension, before the calls.
Detected with `sde64 -ast` FATE job.
Fixes: ace42cf581
Unroll to 16 floats per iteration with four independent accumulators
and reduce them once after the loop.
scalarproduct_float_neon: before after
Apple M1 (clang 16): 0.9 (3.56x) 0.4 (9.18x)
Cortex-A76 (gcc 12.4): 118.7 (4.43x) 85.3 (6.15x)
Signed-off-by: Zhao Zhili <quinkblack@foxmail.com>
These are needed for interop with e.g. libplacebo, which needs to know the
correct flags to call vkGetDeviceQueue2.
Signed-off-by: Niklas Haas <git@haasn.dev>
GPUs filter out denormals when reading floats via imageLoad. Denormals shouldn't
be present in general, but if they are, this is a lossless codec, and we have to
preserve them. This allows reading the exact values.
Sponsored-by: Sovereign Tech Fund
Test the five public functions not already covered by
tests/color_utils: av_csp_luma_coeffs_from_avcsp,
av_csp_primaries_desc_from_id, av_csp_primaries_id_from_desc,
av_csp_approximate_trc_gamma, and av_csp_approximate_eotf_gamma.
Iterates every AVCOL_SPC, AVCOL_PRI, and AVCOL_TRC value including
the extended ranges, round-trips primaries via desc_eq so the
canonical first-match (e.g. smpte170m for smpte240m) is accepted,
checks that a garbage desc returns AVCOL_PRI_UNSPECIFIED, and that
out-of-range enum values return NULL or 0.0 as documented. The
trc/eotf gamma values come from static lookup tables so the
floating point output is bitexact across platforms.
Coverage for libavutil/csp.c: 88.50% -> 94.46%
Test av_ambient_viewing_environment_alloc with and without the size
out-parameter, and av_ambient_viewing_environment_create_side_data.
Verifies the {0, 1} rational defaults set by get_defaults(),
write/read-back of the three AVRational fields, frame side data
attachment, and OOM paths via av_max_alloc.
Coverage for libavutil/ambient_viewing_environment.c: 60.00% -> 100.00%
The issue was that XV30 is a native 444 10-bit format, rather than
16-bits. This resulted in padding leaking into bits where it shouldn't.
Sponsored-by: Sovereign Tech Fund
When s is NULL in av_dynamic_hdr_smpte2094_app5_from_t35, that's not an
allocation error but just invalid API usage. If there is any allocation
failure beforehand that would lead to this, the caller has to check it,
like is already done in all usages of this function in FFmpeg itself.
