Said function has presumably been added in order to check
that we have successfully reset the floating point state
after having violated the ABI/calling convention by not
issuing emms in our MMX DSP routines.
Yet the ability to check this should not have been made public,
because there is no external need for it and because the
function does not even always achieve what its documentation
claims to do: It only works when inline assembly is available.
It should have been implemented in emms.h like emms_c()
(which is where a replacement should be put if there is still
ABI-violating MMX code when av_assert0_fpu() is removed).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, make this code -fshort-enums compatible.
The branch can be optimized away by compilers when
sizeof(enum AVPixelFormat) == sizeof(enum AVSampleFormat).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It was done for the sake of having subblock_duration not be zero as the spec
forbids that value, but harcoding it to any arbitrary value is no better
considering the user is meant to fill the entire structure.
This helps speeding up the function when trying to allocate a struct with a
huge amount of blocks.
Signed-off-by: James Almer <jamrial@gmail.com>
This patch adds screen capture support via AMF vsrc_amf:
ffmpeg -y \
-filter_complex "vsrc_amf=framerate=120:capture_mode=keep_framerate" \
-c:v hevc_amf \
-frames:v 300 \
output_grab.mp4
If the HW frames pool is insufficient,
increase extra_hw_frames in filter_complex.
Name the feature "arm_crc" rather than plain "crc", to make it
clear that this is about a CPU feature extension, not CRC
implementations in general.
This requires dealing with the extension slightly differently
than other extensions, as the name of the feature and the
".arch_extension" extension name differ.
Naming it with an "arm" prefix rather than "aarch64", as the
CPU extension also is available in 32 bit ARM form, even though
we don't intend to use it there.
Implemented the algorithm described in the paper titled
"Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"
by Intel.
It is not used yet; the integration will be added in a separate commit.
Observed near 10x speedup on AMD Zen4 7950x:
av_crc_c: 22057.0 ( 1.00x)
av_crc_clmul: 2202.8 (10.01x)
When a frame is exported to DRM, it may be written to to read to in an asyncronous fashion. Make sure, on unmap of a Vulkan frame that was mapped to DRM, to import any fences that were put on the dmabuf
Both FF_VK_EXT_VIDEO_ENCODE_QUEUE and FF_VK_EXT_VIDEO_MAINTENANCE_1 are
required, not only one of them.
Found by VVL.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
If AVOptionArrayDef.def is NULL, av_opt_is_set_to_default() should return true
when the field in the object is NULL.
Signed-off-by: James Almer <jamrial@gmail.com>
Lone DPBs will only be requested when the implementation requires
a separate DPB. These images are never given out, and are never used for
anything other than a DPB. Also most implementations requiring these
won't support any other usages on DPBs, so limiting the usages would fix
some validation errors.
This reverts commit 8f48a62, 9af8782, and bd3e71b.
Commit 8f48a62 extends tx to 2M, resulting in the tx_float bss
section reaching a size of 4M.
This isn't a issue on devices with normal memory sizes and OS
supporting virtual memory. But it's a real issue for embedded devices
with realtime OS, which may not support virtual memory, e.g., Nuttx.
This 4M of bss section map to physical memory directly, which is a
scarce resource on embedded devices.
