Common symbols are not part of ISO-C and therefore not used
by FFmpeg at all. Yet linker warnings to ensure it stays
that way are nevertheless wrong, because the existence of
common symbols does not imply that there is a bug in our code.
More precisely, Clang's ASAN implementation uses a common symbol
___asan_globals_registered when used on Elf targets with
the -fsanitize-address-globals-dead-stripping option;
said option is the default since Clang 17 [1].
This leads to 1883 warnings about ___asan_globals_registered
when linking here.
(Even without that option there were warnings like
_ZN14__interception10real_vforkE being overridden.)
Said warning is also unnecessary: The proper way to ensure
that our code is free of common symbols is to let the compiler
enforce this. But this is already the default since GCC 10
and Clang 11, so there is no risk of introducing our own
common symbols.
[1]: https://reviews.llvm.org/D152604
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The configure check already had fallback for the previous version
of glslang, which had different requirements for flags.
This commit simply moves the flags needed for glslang 13 to the
fallback, while first trying to use new flags for glslang 14.
This drops support for ~3 year old glslang versions, which
I'm not sure had the complete C API we're using anyway.
It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.
Note that stdatomic.h is still emulated on MSVC, as current versions
require the /experimental:c11atomics, and do not support
ATOMIC_VAR_INIT() anyway.
option kernel_driver for vaapi device creation can be used to choose the
desired device on Linux, which is more convenient than DRM render node
in a multiple-device system (e.g. Intel iGPU + AMD dGPU or inverse), but
this option requires libdrm works. vaapi is autodetected at
configuration time, let's make libdrm autodetected too.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The check for this option does succeed - MSVC accepts the option,
but prints a warning about it being unknown and ignored, for
each compiled object file:
cl : Command line warning D9002 : ignoring unknown option '-mfp16-format=ieee'
The configure script only attempts to add this option on ARM,
therefore this warning isn't seen by the majority of people
building with MSVC.
Making this option into a no-op probably isn't entirely right,
but on the other hand, we don't want to litter the code that
checks for support for the option with compiler specific
conditions either.
Signed-off-by: Martin Storsjö <martin@martin.st>
The file libavcodec/x86/mlpdsp_init.c uses inline assembly with
nonlocal labels that are referenced outside of the assembly in C.
This fails to link with LTO when built with Clang when targeting
Windows.
The root cause has been reported upstream at
https://github.com/llvm/llvm-project/issues/76046.
Fixes: https://trac.ffmpeg.org/ticket/10548
Signed-off-by: Martin Storsjö <martin@martin.st>
vvc decoder plug-in to avcodec.
split frames into slices/tiles and send them to vvc_thread for further decoding
reorder and wait for the frame decoding to be done and output the frame
Features:
+ Support I, P, B frames
+ Support 8/10/12 bits, chroma 400, 420, 422, and 444 and range extension
+ Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF, LMCS, ALF
+ 295 conformace clips passed
- Not support RPR, IBC, PALETTE, and other minor features yet
Performance:
C code FPS on an i7-12700K (x86):
BQTerrace_1920x1080_60_10_420_22_RA.vvc 93.0
Chimera_8bit_1080P_1000_frames.vvc 184.3
NovosobornayaSquare_1920x1080.bin 191.3
RitualDance_1920x1080_60_10_420_32_LD.266 150.7
RitualDance_1920x1080_60_10_420_37_RA.266 170.0
Tango2_3840x2160_60_10_420_27_LD.266 33.7
C code FPS on a M1 Mac Pro (ARM):
BQTerrace_1920x1080_60_10_420_22_RA.vvc 58.7
Chimera_8bit_1080P_1000_frames.vvc 153.3
NovosobornayaSquare_1920x1080.bin 150.3
RitualDance_1920x1080_60_10_420_32_LD.266 105.0
RitualDance_1920x1080_60_10_420_37_RA.266 133.0
Tango2_3840x2160_60_10_420_27_LD.266 21.7
Asm optimizations still working in progress. please check
https://github.com/ffvvc/FFmpeg/wiki#performance-data for the latest
Contributors (based on code merge order):
Nuo Mi <nuomi2021@gmail.com>
Xu Mu <toxumu@outlook.com>
Frank Plowman <post@frankplowman.com>
Shaun Loo <shaunloo10@gmail.com>
Wu Jianhua <toqsxw@outlook.com>
Thank you for reporting issues and providing performance reports:
Łukasz Czech <lukaszcz18@wp.pl>
Xu Fulong <839789740@qq.com>
Thank you for providing review comments:
Ronald S. Bultje <rsbultje@gmail.com>
James Almer <jamrial@gmail.com>
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Co-authored-by: Xu Mu <toxumu@outlook.com>
Co-authored-by: Frank Plowman <post@frankplowman.com>
Co-authored-by: Shaun Loo <shaunloo10@gmail.com>
Co-authored-by: Wu Jianhua <toqsxw@outlook.com>
The function lf_db_new was deprecated in lensfun 09dcd3e7ad in 2017
in favour of lf_db_create. The AVfilter was adjusted in 8b78eb312d
but the configure check wasn't changed.
lensfun removed lf_db_new declaration in lf 35c0017593 so configure
fails to find lensfun.
Fixes the build. It's a requirement when utilizing PIE.
Signed-off-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The check for UWP mode was duplicated from right above, in
d54127c41a.
Also, instead of several lines with "enabled uwp && ...", make one
"if enabled uwp; then" block.
Signed-off-by: Martin Storsjö <martin@martin.st>
This disables regenerating ffversion.h whenever the checked out
git commit changes, speeding up development rebuilds.
Whenever this option is set, force the version to be printed as
"unknown" rather than showing potentially stale information.
Signed-off-by: Martin Storsjö <martin@martin.st>
The implementation is based on:
https://learn.microsoft.com/en-us/windows/win32/medfound/direct3d-12-video-overview
With the Direct3D 12 video decoding support, we can render or process
the decoded images by the pixel shaders or compute shaders directly
without the extra copy overhead, which is beneficial especially if you
are trying to render or post-process a 4K or 8K video.
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua <toqsxw@outlook.com>
Signed-off-by: Tong Wu <tong1.wu@intel.com>
With the way the runtime checks are currently set up, every single
openh264 release, no matter how minor, is considered an ABI break and
requires ffmpeg recompilation. This is unnecessarily strict because it
doesn't allow downstream distributions to ship any openh264 bug fix
version updates without breaking ffmpeg's openh264 support.
Years ago, at the time when ffmpeg's openh264 support was merged,
openh264 releases were done without a versioned soname (the library was
just libopenh264.so, unversioned). Since then, starting with version
1.3.0, openh264 has started using versioned sonames and the intent has
been to bump the soname every time there's a new release with an ABI
change.
This patch drops the exact version check and instead adds a minimum
requirement on 1.3.0 to the configure script.
Signed-off-by: Kalev Lember <klember@redhat.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
It's available on macOS since 10.8, but not available on iOS until
16.0.
Reported and tested by xufuji456.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
libvpl deprecated some symbols (e.g. MFX_EXTBUFF_VPP_DENOISE2 is used to
replace MFX_EXTBUFF_VPP_DENOISE), however the new symbols aren't support
by MediaSDK runtime. In order to support the combination of libvpl and
MediaSDK runtime on legacy devices, we continue to use the deprecated
symbols in FFmpeg. This patch added -DMFX_DEPRECATED_OFF to CFLAGS to
silence the corresponding compilation warnings.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This is only supported at compilation time. If Zfhmin is supported, then
conversions are fast, which is what the flag is used for. At this time,
run-tiem detection is not possible, as in not supported by Linux. But even
if it were, the current FFmpeg approach seems unable to deal with it (same
problem as on x86, really).
This commit adds support for VP8 bitstream read methods to the cbs
codec. This enables the trace_headers bitstream filter to support VP8,
in addition to AV1, H.264, H.265, and VP9. This can be useful for
debugging VP8 stream issues.
The CBS VP8 implements a simple VP8 boolean decoder using GetBitContext
to read the bitstream.
Only the read methods `read_unit` and `split_fragment` are implemented.
The write methods `write_unit` and `assemble_fragment` return the error
code AVERROR_PATCHWELCOME. This is because CBS VP8 write is unlikely to
be used by any applications at the moment. The write methods can be
added later if there is a real need for them.
TESTS: ffmpeg -i fate-suite/vp8/frame_size_change.webm -vcodec copy
-bsf:v trace_headers -f null -
Signed-off-by: Jianhui Dai <jianhui.j.dai@intel.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Partially fixes ticket #798
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Peter Ross <pross@xvid.org>
The test can currently pass when _Pragma is not supported, since
_Pragma might be treated as a implicitly declared function.
This happens e.g. with tinycc.
Extending the check to 2 pragmas both matches the actual use
better and avoids this misdetection.
Clang versions before 17 (Xcode versions up to and including 15.0)
had a very annoying bug in its behaviour of the ".arch" directive
in assembly. If the directive only contained a level, such as
".arch armv8.2-a", it did validate the name of the level, but it
didn't apply the level to what instructions are allowed. The level
was applied if the directive contained an extra feature enabled,
such as ".arch armv8.2-a+crc" though. It was also applied on the
next ".arch_extension" directive.
This bug, combined with the fact that the same versions of Clang
didn't support the dotprod/i8mm extension names in either
".arch <level>+<feature>" or in ".arch_extension", could lead to
unexepcted build failures.
As the dotprod/i8mm extensions couldn't be enabled dynamically
via the ".arch_extension" directive, someone building ffmpeg could
try to enable them by configuring their build with
--extra-cflags="-march=armv8.6-a".
During configure, we test for support for the i8mm instructions
like this:
# Built with -march=armv8.6-a
.arch armv8.2-a # Has no visible effect here
#.arch_extension i8mm # Omitted as the extension name isn't known
usdot v0.4s, v0.16b, v0.16b
# Successfully assembled as armv8.6-a is the effective level,
# and i8mm is enabled implicitly in armv8.6-a.
Thus, we would enable assembling those instructions. However if
we later check for another extension, such as sve (which those
versions of Clang actually do support), we can later run into the
following situation when building actual code:
# Built with -march=armv8.6-a
.arch armv8.2-a # Has no visible effect here
#.arch_extension i8mm # Omitted as the extension name isn't known
.arch_extension sve # Included as "sve" is as supported extension name
# .arch_extension effectively activates the previous .arch directive,
# so the effective level is armv8.2-a+sve now.
usdot v0.4s, v0.16b, v0.16b
# Fails to build the instructions that require i8mm. Despite the
# configure check, the unrelated ".arch_extension sve" directive
# breaks the functionality of the i8mm feature.
This patch avoids this situation:
- By adding a dummy feature such as "+crc" on the .arch directive
(if supported), we make sure that it does get applied immediately,
avoiding it taking effect spuriously at a later unrelated
".arch_extension" directive.
- By checking for higher arch levels such as armv8.4-a and armv8.6-a,
we can assemble the dotprod and i8mm extensions without the user
needing to pass -march=armv8.6-a. This allows using the dotprod/i8mm
codepaths via runtime detection while keeping the binary runnable
on older versions. I.e. this enables the i8mm codepaths on Apple M2
machines while built with Xcode's Clang.
TL;DR: Enable the I8MM extensions for Apple M2 without the user needing
to do a custom configuration; avoid potential build breakage if a user
does such a custom configuration.
Once Xcode versions that have these issues fixed are prevalent, we
can consider reverting this change.
Signed-off-by: Martin Storsjö <martin@martin.st>
This patch adds two MSZ (Middle Size; half width) character
related options, mapping against newly added upstream
functionality:
* `replace_msz_japanese`, which was introduced in version 1.0.1
of libaribcaption.
* `replace_msz_glyph`, which was introduced in version 1.1.0
of libaribcaption.
The latter option improves bitmap type rendering if specified
fonts contain half-width glyphs (e.g., BIZ UDGothic), even
if both ASCII and Japanese MSZ replacement options are set
to false.
As these options require newer versions of libaribcaption, the
configure requirement has been bumped accordingly.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
At various points through the function librsvg_decode_frame, errors are
returned from immediately without deallocating any allocated structs.
This patch both fixes those leaks, and also fixes the use of functions
that are deprecated since librsvg version 2.52.0. The older calls are
still used, guarded by #ifdefs while the newer replacements are used if
librsvg >= 2.52.0. One of the deprecated functions is used as a check
for the configure shell script, so it was replaced with a different
function.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The libmfx deprecation warning tells you to build against libmfx 1.x,
but the actual solution is to use --enable-libvpl instead of using
--enable-libmfx. Update the warning message to reflect this.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
0cd8769207 utilized the rc_algorithm member of the kvz_config struct, which
was introduced in Kvazaar 2.0.0. This patch bumps the minimum version of
Kvazaar to 2.0.0 so that FFmpeg compiles successfully.
Signed-off-by: John Mather <johnmather@sidefx.com>
The custom-allocator logic has been completely defunct since a while,
since nothing depends on those targets, they never get used.
This updates jemalloc to pkg-config, adds the fallback option for
potential arbitrary allocators, and finally actually adds the libraries
to LDFLAGS.
They were replaced by TX from libavutil; the tremendous work
to get to this point (both creating TX as well as porting
the users of the components removed in this commit) was
completely performed by Lynne alone.
Removing the subsystems from configure may break some command lines,
because the --disable-fft etc. options are no longer recognized.
Co-authored-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVDCT API used by this filter does in no way depend
upon the FFT subsystem.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Keeping an ever growing list of CPUs just to pass -march to the compiler and
enable fast_cmov is a waste of time. Every CPU we know has limitations is
already handled here, so just fallback to enabling everything when a passed in
argument is not one of those.
This will enable optimizations for CPU architectures released in the past 7 or
so years with supported GCC and clang compilers when used as argument in
configure, instead of silently ignoring them.
Signed-off-by: James Almer <jamrial@gmail.com>
Avoid using the deprecated functions ssh_try_publickey_from_file among
others in favor of symbols introduced in libssh 0.6.0 (Jan 2014) and
update configure to require this version.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
OpenVINO API 2.0 was released in March 2022, which introduced new
features.
This commit implements current OpenVINO features with new 2.0 APIs. And
will add other features in API 2.0.
Please add installation path, which include openvino.pc, to
PKG_CONFIG_PATH mannually for new OpenVINO libs config.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
ddc1cd5cdd defined WIN32_LEAN_AND_MEAN
globally, which makes for much fewer transitive includes from
windows.h. With that define, CoTaskMemFree no longer gets
implicitly declared by just including windows.h, but one has to
include the right header objbase.h too.
That commit caused ole32 to no longer get detected, which caused
dxva2 to no longer be enabled. This gets fixed by this patch.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
This commit is the AVHWAccel analogue of commit
20f9727018: It moves the private fields
of AVHWAccel to a new struct FFHWAccel extending AVHWAccel
in an internal header (namely hwaccel_internal.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVISYNTH_INTERFACE_VERSION 10 fell in-between the releases of
3.7.2 and 3.7.3, and is required to be able to read the channel
layout information.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
av_random_bytes() can use OS provided strong random functions and does not
depend soley on openssl/gcrypt external libraries.
Fixes ticket #10441.
Signed-off-by: Marton Balint <cus@passwd.hu>
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>
Add CodedBitstreamContext to parse VPS,SPS,PPS in VVC nal units.
Implement parsing and writing of SPS,PPS,VPS,PH,AUD,SEI and slices.
Add ff_cbs_type_h266 to cbs types tables and AV_CODEC_ID_H266
to cbs codec ids.
Co-authored-by: Thomas Siedel <thomas.ff@spin-digital.com>
Signed-off-by: James Almer <jamrial@gmail.com>
- text is now shaped using libharfbuz
- glyphs position is now accurate to 1/4 pixel in both directions
- the default line height is now the one defined in the font
Adds libharfbuzz dependency.
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
For now, there's not much value in this since Clang don't support
enabling the dotprod or i8mm features with either .arch_extension
or .arch (it has to be enabled by the base arch flags passed to
the compiler). But it may be supported in the future.
Signed-off-by: Martin Storsjö <martin@martin.st>
These are available since ARMv8.4-a and ARMv8.6-a respectively,
but can also be available optionally since ARMv8.2-a.
Check if ".arch armv8.2-a" and ".arch_extension {dotprod,i8mm}" are
supported, and check if the instructions can be assembled.
Current clang versions fail to support the dotprod and i8mm
features in the .arch_extension directive, but do support them
if enabled with -march=armv8.4-a on the command line. (Curiously,
lowering the arch level with ".arch armv8.2-a" doesn't make the
extensions unavailable if they were enabled with -march; if that
changes, Clang should also learn to support these extensions via
.arch_extension for them to remain usable here.)
Signed-off-by: Martin Storsjö <martin@martin.st>
