It is not necessary at all. So remove it.
This also breaks an inclusion cycle mem.h->avutil.h->common.h->mem.h.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, avutil.h includes common.h which includes mem.h which
includes avutil.h, so that all these headers are in fact equivalent.
Yet mem.h does not need to include avutil.h at all and when it no longer
does, including common.h will no longer include error.h (included by
avutil.h) as well; change this by moving error.h to avutil.h, as error.h
is clearly a commonly used header.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These are in-place transforms, required for DCT-I and DST-I.
Templated as the mod2 variant requires minor modifications, and is
required specifically for DCT-I/DST-I.
The loader ensures only that functions with tagged supported extensions
exist, rather than ensuring only those with supported extensions are
loaded.
As the init function uses Vulkan functions, whose loading requires them
to have the extension flags set, the extension flags are guaranteed
to also exist at this point.
So far, AV_READ_TIME would return the cycle counter. This posed two
problems:
1) On recent systems, it would just raise an illegal instruction
exception. Indeed RDCYCLE is blocked in user space to ward off some
side channel attacks. In particular, this would cause the random
number generator to crash.
2) It does not match the x86 behaviour and the apparent original intent
of AV_READ_TIME in the functional code base (outside test cases).
So this replaces the cycle counter with the time counter. The unit is
a platform-dependent constant fraction of time, and the value should be
stable across harts (RISC-V lingo for physical CPU thread).
Currently, create_pnext is only used if an applicable external memory
extension is enabled. This will usually the case when used from the command
line, but may not be when the Vulkan context is created manually.
For images used in video decoding, create_pnext contains the video profile
list, which is mandatory.[1] This fixes a GPU crash when using RADV.
[1] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageCreateInfo.html#VUID-VkImageCreateInfo-usage-04815
Signed-off-by: Chris Spencer <spencercw@gmail.com>
This abstraction is similar to the existing one for pthread_mutex_t and
pthread_once_t functions, and should reduce the amount of ifdeffery used
in future code.
Signed-off-by: James Almer <jamrial@gmail.com>
C++ doesn't support designated initializers until C++20. We have
a bunch of pre-defined channel layouts, the gains to make them
usable in C++ exceed the losses.
Bump minor version so C++ project can check before use these defines.
Also initialize .opaque field explicitly to reduce warning in C++.
Signed-off-by: James Almer <jamrial@gmail.com>
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
Specifically, test copying a channel layout with custom order,
so that the allocation codepath of av_channel_layout_copy()
is executed.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This test does not need access to the internals of said compilation
unit.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_channel_name(), av_channel_description() and
av_channel_layout_describe() are supposed to return the size
of the needed buffer to allow the user to check for truncation;
the documentation ("If the returned value is bigger than buf_size,
then the string was truncated.") confirms that size does not
mean strlen.
Yet the AVBPrint API, i.e. AVBPrint.len, does not account for
the terminating '\0'. Therefore the returned length is off by one.
Furthermore, also check for whether the returned value actually
fits in an int (which is the return value of these functions).
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVBPrint API guarantees that the string buffer is always
zero-terminated; in order to honour this guarantee, there
obviously must be a string buffer at all and it must have
a size >= 1. Therefore av_bprint_init_for_buffer() treats
passing a NULL buffer or size == 0 as invalid data that
leads to undefined behaviour, namely NPD in case NULL is provided
or a write to a buffer of size 0 in case size == 0.
But it would be easy to support this, namely by using the internal
buffer with AV_BPRINT_SIZE_COUNT_ONLY in case size == 0.
There is a reason to allow this: Several functions like
av_channel_(description|name) are actually wrappers
around corresponding AVBPrint functions. They accept user
provided buffers and are supposed to return the required
size of the buffer, which would allow the user to call
it once to get the required buffer size and call it once
more after having allocated the buffer.
If av_bprint_init_for_buffer() treats size == 0 as invalid,
all these users would need to check for this themselves
and basically add the same codeblock that this patch
adds to av_bprint_init_for_buffer().
This change is in line with e.g. snprintf() which also allows
the pointer to be NULL in case size is zero.
This fixes Coverity issues #1503074, #1503076 and #1503082;
all of these issues are about providing NULL to the channel-layout
functions that are wrappers around AVBPrint versions.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use the GCC specific codepath for Clang in MSVC mode too.
This matches the condition used in a number of other places.
MSVC doesn't have a way to signal potential aliasing, while GCC
(and Clang) can use __attribute__((may_alias)) for this purpose.
When building with Clang in MSVC mode, __GNUC__ isn't defined but
_MSC_VER is as Clang primarily impersonates MSVC - but even then it
does support the GCC style attributes.
The GCC specific codepath uses av_alias, which expands to
the may_alias attribute if supported. The MSVC specific codepath
doesn't use av_alias so far (as MSVC doesn't support any
corresponding attribute).
This fixes a couple HEVC decoder tests when built with Clang 14 or
newer in MSVC mode (with issues observed on all of x86_64, armv7
and aarch64).
Signed-off-by: Martin Storsjö <martin@martin.st>
libavutil/hwcontext_qsv.c: In function ‘qsv_map_to’:
libavutil/hwcontext_qsv.c:1905:47: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
major/minor are in <sys/types.h> on BSDs and <sys/mkdev.h> on Solaris-like.
libavutil/hwcontext_vulkan.c:55:10: fatal error: 'sys/sysmacros.h' file not found
#include <sys/sysmacros.h>
^~~~~~~~~~~~~~~~~
1) Take the reductive sum out of the loop,
leaving a regular vector addition in the loop.
2) Merge the addition and the multiplication.
3) Unroll.
Before:
scalarproduct_float_rvv_f32: 832.5
After:
scalarproduct_float_rvv_f32: 275.2
The code was blindly assuming that Zbb or V implied Zba. While the
earlier is practically always true, the later broke some QEMU setups,
as V was introduced earlier than Zba.
This is not actually used for anything. The configure check causes the
CPU feature flag to be set, but nothing consumes it at all.
While AArch64 does have VFP, it is only used for the scalar C code.
Conversely, it is still possible to disable VFP, by changing the
C compiler flags as before (though that only makes sense for an
hypothetical non-standard Armv8 platform without VFP).
Note that this retains the "vfp" option flag, for backward
compatibility and on the very remote but theoretically possible chance
that FFmpeg actually makes use of it in the future.
AV_CPU_FLAG_VFP is retained as it is actually used by AArch32.
libavutil/random_seed.c calls arc4random_buf which is
not available on OSX 10.4 Tiger, but the configuration
script tests for arc4random which is available.
Fix the configuration test to match the actual API used.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>