This adds the Linux-specific function call to detect CPU features. Unlike
the more portable auxillary vector, this supports extensions other than
single lettered ones. At this point, FFmpeg already needs this to detect
Zba and Zbb at run-time, and probably will need it for Zvbb in the near
future.
Support will be available in glibc 2.40 onward.
Clarify comment regarding type of integers regarding AV_OPT_TYPE_IMAGE_SIZE.
Signed-off-by: Marcus B Spencer <marcus@marcusspencer.xyz>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is a common error code from e.g. CDNs or cloud storage, and
it is useful to be able to handle it differently to a generic
4XX code.
Its source is RFC6585.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
av_mastering_display_metadata_alloc() is not useful in scenarios where you need to
know the runtime size of AVMasteringDisplayMetadata.
Signed-off-by: James Almer <jamrial@gmail.com>
* SMPTE ST 2128 IPT-C2 defines the coefficients utilized in DoVi
Profile 5. Profile 5 can thus now be represented in VUI as
{AVCOL_RANGE_JPEG, AVCOL_PRI_BT2020, AVCOL_TRC_SMPTE2084,
AVCOL_SPC_IPT_C2, AVCHROMA_LOC_LEFT} (although other chroma
sample locations are allowed). AVCOL_TRC_SMPTE2084 should in
this case be interpreted as 'PQ with reshaping'.
* YCgCo-Re and YCgCo-Ro define the bitexact YCgCo-R, where the
number of bits added to a source RGB bit depth is 2 (i.e., even)
and 1 (i.e., odd), respectively.
As well as accessors plus a function for allocating this struct with
extension blocks,
Definitions generously taken from quietvoid/dovi_tool, which is
assembled as a collection of various patent fragments, as well as output
by the official Dolby Vision bitstream verifier tool.
The NLQ pivots are not documented but should be present in the header
for profile 7 RPU format. It has been verified using Dolby's
verification toolkit.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
struct Foo * declares a new type (namely struct Foo)
if there is no declaration of struct Foo already visible
in the current scope; otherwise it is just a pointer to
an element of the already declared type "struct Foo".
There is a gotcha with the first case:
struct Foo is only declared in its scope; a later declaration
of struct Foo in an enclosing scope declares a different type.
This happens in hwcontext_vulkan.h if it is included before
hwcontext.h, because some declarations of struct AVHWDeviceContext
and struct AVHWFramesContext have function prototype scope.
Compilers warn about this (during checkheaders):
‘struct AVHWDeviceContext’ declared inside parameter list will not
be visible outside of this definition or declaration
Fix this by including hwcontext.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move AV_CHECK_OFFSET to its only user, namely
lavc/arm/mpegvideo_arm.c and rename it to CHECK_OFFSET.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also update the checks that guard against inserting
a new enum entry in the middle of a range.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
GCC 9-13 do not emit warnings for this at all optimization
levels even when -Wmaybe-uninitialized is not disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
C11 required to use ATOMIC_VAR_INIT to statically initialize
atomic objects with static storage duration. Yet this macro
was unsuitable for initializing structures [1] and was actually
unneeded for all known implementations (this includes our
compatibility fallback implementations which simply wrap the value
in parentheses: #define ATOMIC_VAR_INIT(value) (value)).
Therefore C17 deprecated the macro and C23 actually removed it [2].
Since commit 5ff0eb34d2b1089d3dd9f27fdb51520001709138 we default
to C17 if the compiler supports it; Clang warns about ATOMIC_VAR_INIT
in this mode. Given that no implementation ever needed this macro,
this commit stops using it to avoid this warning.
[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_485
[2]: https://en.cppreference.com/w/c/atomic/ATOMIC_VAR_INIT
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A pointer conversion is UB if the resulting pointer is not
correctly aligned for the resultant type, even if no
load/store is ever performed through that pointer (C11 6.3.2.3 (7)).
This may happen in opt_copy_elem(), because the pointers are
converted even when they belong to a type that does not guarantee
sufficient alignment.
Fix this by deferring the cast after having checked the type.
Also make the casts -Wcast-qual safe and avoid an indirection
for src.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not documented to be safe and in any case it is nonsense:
Currently av_strdup(NULL) returns NULL and in order to distinguish
this from a genuine allocation failure, opt_copy_elem()
checked afterwards whether src was actually NULL. But then one
can simply check in advance whether one should call av_strdup()
at all.
set_string() was even worse and returned ENOMEM in case the value
to be duplicated is NULL; this only worked because
av_opt_set_defaults2() does not check the return value at all
(given that it can't propagate it).
These two places account for 389114 of 390356 av_strdup(NULL)
calls during one FATE run.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
