One of the design goals of this macro is the ability to support static
inline predicate functions. Which is emitting warning in clang that a
function may have side-effects and the condition will be ignored. MSVC
doesn't emit warning, but also ignore predicate in such cases.
Instead of using assume builtins, implement it using unreachable. Which
solves this case for MSVC and Clang.
This reverts ea56fe60ac, but also extends
it to MSVC, which is affected in the similar way.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
AV_CLASS_CATEGORY_HWDEVICE was introduced in the past but
no corresponding colors were added for non-Win32 platforms.
Fixes bf1579c ("avutil/log,hwcontext: Add AV_CLASS_CATEGORY_HWDEVICE")
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
vaapi_get_image_format() will be called in vaapi_map_frame().
So it's a double check, drop it to avoid redundancy.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
There's a race condition for YUV420P when mapping from pix_fmt
to VA fourcc, both I420 and YV12 could be found by pix_fmt.
Currently, vaapi_get_image_format() iterates over the query results
of pix_fmt and returns the first matching result in the order
declared in the driver. This may result in an incorrect image_format.
Now use fourcc to find the image_format.
Fixes:
ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i INPUT \
-vf scale_vaapi=format=yuv420p,hwmap,format=yuv420p \
-vframes 1 -f rawvideo -y yuv420p.yuv
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Previously, it was assumed that `drmFormatModifierPlaneCount` was one
for all modifiers when exporting, which is not always the case, in
particular for AMD GPUs and maybe others.
Fetch the number of memory planes and fill the structs appropriately in this situation.
The encoded stream is still bad in the case whre modifers are involved,
but I think this patch still stands on its own and I suspect that may be a driver bug.
A potential improvement that could be make is to cache the format
information, so we can avoid the two GetPhysicalDeviceFormatProperties2
calls for each export, as well as the allocation. I doubt this is very
expensive, but seemed worth noting.
v2 changes: query the format properties with the test image created in
`vulkan_frames_init` to avoid allocating space for the query during
export
Signed-off-by: Russell Greene <russellgreene8@gmail.com>
This commit introduces a new hardware-accelerated video filter, scale_d3d11,
which performs scaling and format conversion using Direct3D 11. The filter enables
efficient GPU-based scaling and pixel format conversion (p010 to nv12), reducing
CPU overhead and latency in video pipelines.
This change improves pipeline stability and reduces
dynamic GPU surface allocations when using AMF with copy_frame = 1.
This optimization has no negative effect.
Add type removed function wrappers to resolve UB of calling function
through pointer to incorrect function type.
Fixes: FATE-{hmac,srtp}
Fixes: call to function av_md5_init through pointer to incorrect
function type 'void (*)(void *)' and similar for others.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
av_get_token() allocates an output buffer with the same size as the
input. Generally, this is harmless, but when the input string is large
and consists of many small tokens, calling av_get_token() repeatedly to
extract all tokens will significantly amplify memory allocations.
To fix this, after obtaining the return value, simply realloc the buffer
to the actual size needed for output string.
Fixes OOM when parsing filter graph string.
Fixes OSS-Fuzz: 394983446
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
If the image data is not at the start of the buffer allocation, such as
when the buffer has padding before the image data, this function maps too
much memory, since src_data + src_buf->size exceeds the buffer size.
Fix this by subtracting the difference between the buffer start and the
provided image data pointer from the size of the memory range to map.
An easy way to reproduce this issue is using the vf_pad filter, which
allocates image data buffers with a nonzero offset whenever padding is
requested before the start of the image data.
The issue is that vulkan_device_create_internal() is only called for
devices that lavu creates by itself.
For external devices, this was never done.
This also solves some mid-function declaration warnings.
This feature fundamentally relies on host-visible VRAM, which restricts the
set of available memory types to (typically) host-visible device-local ones.
When resizable BAR is disabled, this memory type is usually limited to
e.g. 256 MiB in size, which is just plain insufficient for allocation of
general purpose GPU images, causing OOM errors on even the simplest of
commands.
The easiest solution is to disable host transfers entirely on machines
without host-addressable VRAM. In theory, we could try and recover the use
of host transfers for images which are *not* restricted to device-local
memory types, but this is rarely the case in practice, and the effort
required would exceed the benefit, especially since ReBAR is a standard
feature on all platforms recent enough to have Vulkan drivers, and only
occasionally disabled in the UEFI for by default for some hare-brained
notion of "backwards compatibiility" with ancient software.
This fixes building with Clang in MSVC mode, for x86, which was
broken in 6e49b86996 (in Nov 2024);
previously it failed with undefined symbols for the constants
defined with DECLARE_ASM_CONST, accessed via inline assembly.
Before 57861911a3, there was an
#elif defined(__GNUC__) || defined(__clang__)
case before the
#elif defined(_MSC_VER)
case for defining DECLARE_ASM_CONST, which included av_used.
(This case included the explicit "defined(__clang__)" since
f637046d31.)
After 57861911a3, it used the
generic definition of DECLARE_ASM_CONST that also included
av_used - which also worked for Clang in MSVC mode. But after
6e49b86996, Clang in MSVC mode
ended up using the MSVC specific variant which lacked the
av_used declaration, causing linker errors due to undefined
symbols.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix incorrect enum value used in color primaries check by replacing
AVCOL_SPC_UNSPECIFIED with AVCOL_PRI_UNSPECIFIED.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Fixes use of bultins on clang x86_64-pc-windows-msvc which does not
define any __GNUC__. Also on other targets __GNUC__ is defined to 4 by
default, so any feature testing based on version is not really valid.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>