While we only add the flag if the linker seems to support it,
it turns out that ld.bfd had a bug where the flag is accidentally
accepted, and the flag produces an output file named
"_warn_duplicate_libraries".
The ld.bfd bug was fixed in binutils 2.36, in
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3991c7acb29aa8d7d52150695eb3efa03a08dd50.
Signed-off-by: Martin Storsjö <martin@martin.st>
spirv_compiler is an undeclared variable that was spontaneously
enabled if libshaderc or libglslang were detected, and served as
a way to enable filters.
However, it being undeclared had the effect that it was neither
considered explicitly disabled nor enabled if libshaderc or
libglslang were detected.
The only category we have which explicitly disables variables
is EXTERNAL_LIBRARY_LIST, however, spirv_compiler is not a real
external library, and making it present there would report its
detection on ./configure.
If someone were to enable libglslang/libshaderc, and then disable
all Vulkan filters, they would have the same issue as the earlier
fix for libavcodec.
893f3fde4c made libavcodec link to libshaderc/libglslang, though
no codecs depend on it at this immediate moment.
This was merged largely as a coordination effort to synchronize three
different developers' repositories to allow them to send patches without
overlapping functionality in between.
This line can be removed once the first component to depend on spirv_compiler
lands, but leaving it in is fine too.
We started defauling to nasm 8 years ago.
We are still compatible with yasm 0.8.0, released in 2009. **15 years ago**.
The time has more than come to remove support for it.
Maintaining compatibility started cutting into writing new code long ago.
We still can't have 2-argument instructions, preprocessor booleans, and all
AVX2 code must still be wrapped in ifdefs. Newly added code often breaks this.
This silences a lot of compile warnings (around 160 instances at least), when
compiling with Clang.
These warnings look like this:
libavformat/http.c:176:133: warning: implicit conversion from 'long long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-const-int-float-conversion]
176 | { "end_offset", "try to limit the request to bytes preceding this offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
| ~ ^~~~~~~~~
Signed-off-by: Martin Storsjö <martin@martin.st>
Use AV1DecContext's current_obu to access the original OBUs, and
feed them to videotoolbox, rather than the bare slice data passed
via decode_slice.
This requires a small addition to AV1DecContext, for keeping track
of the current range of OBUs that belong to the current frame.
Co-authored-by: Ruslan Chernenko <ractyfree@gmail.com>
Co-authored-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Martin Storsjö <martin@martin.st>
Since Xcode 15, macOS developer tools use a new linker. The new
linker by default warns for duplicate -l options. As this is a
known and expected thing, not to be considered an issue, ask for
the warning to be silenced.
This silences linker warnings like this:
ld: warning: ignoring duplicate libraries: '-lc++', '-lcrypto', '-lm', '-logg', '-lpthread', '-lssl', '-lvorbis', '-lvpx', '-lz'
The linker can also warn about duplicate -rpath options, and there's
currently no option to silence those warnings.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously only the C compiler was set, which would lead to
confusing situations where even though clang-asan was selected,
it would still use g++ for C++ code, failing because configure
does not support mixing compilers in this way (which is a separate
issue not addressed by this commit).
The symbol prefix check would incorrectly detect a bogus prefix in
circumstances where sanitizers instrument the build, like when
configuring with the clang-asan toolchain where it would detect the
prefix as __odr_asan_gen_, which is obviously wrong.
To fix this, adjust the prefix detection to only detect a
one-character prefix, which is the only case that matters
anywhere right now.
This commit adds the first Vulkan hardware encoder.
Currently, P, and **B**-frames are supported. This marks the
first implementation to support both.
The encoder has feature-parity with VAAPI.
This commit adds the common Vulkan video encoding framework.
It makes full use of the asynchronous features of our new common
hardware encoding code, and of Vulkan.
The code is able to handle anything from H264 to AV1 and MJPEG.
configure use "-Wl,-framework,foo" and "-framework foo" to specify
dependencies on Apple frameworks. These two styles essentially do
the same thing when build ffmpeg. However, they do make difference
when generate pkg-config files. Some tools interact with pkg-config
cannot handle "-Wl,-framework,foo" in Libs field, e.g., cmake with
pkg_check_modules.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Should make strict compilers happy.
Also, make AV_COPY128 use integer operations while at it. Removing the
inclusion of immintrin.h ensures a lot less intrinsic related headers are
included as well, which fixes a clash of defines with some Clang versions.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: James Almer <jamrial@gmail.com>
This has the benefit of removing any SSE -> AVX penalty that may happen when
the compiler emits VEX encoded instructions.
Signed-off-by: James Almer <jamrial@gmail.com>
When called inside a loop, the inline asm version results in one pxor
unnecessarely emitted per iteration, as the contents of the __asm__() block are
opaque to the compiler's instruction scheduler.
This is not the case with intrinsics, where pxor will be emitted once with any
half decent compiler.
This also has the benefit of removing any SSE -> AVX penalty that may happen
when the compiler emits VEX encoded instructions.
Signed-off-by: James Almer <jamrial@gmail.com>
This implementation is based on D3D12 Video Encoding Spec:
https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
Sample command line for transcoding:
ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
-c:v hevc_d3d12va output.mp4
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Currently, any unrecognised platform is treated as 32-bit. This should
detect *most* 64-bit platforms, namely LP64 and LLP64 ones.
Unfortunately this will not work for ILP32 ABIs on 64-bit ISAs, but
still better than nothing.
Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,qpa,period,
passlogfile,stats,vvenc-params,level,tier.
Enable encoder by adding --enable-libvvenc in configure step.
Co-authored-by: Christian Bartnik chris10317h5@gmail.com
Signed-off-by: Thomas Siedel <thomas.ff@spin-digital.com>
The vendor has long since switched to Arm, with the last product
reaching their official end-of-life over 11 years ago. Linux support for
the ISA was dropped 7 years ago. More importantly, this architecture was
never supported by upstream GCC, and the vendor fork is stuck at version
4.2, which FFmpeg no longer supports (as per C11 requirement).
Presumably, this is still the case given the lack of vendor support.
Indeed all of the code being removed here consisted of inline assembler
scalar optimisations. A sane C compiler should be able to perform those
automatically nowadays (with the sole exception of fast CLZ detection),
but this is moot as this architecture is evidently dead.
Martin Storsjö
vipyne
Min Chen
Lynne
Lynne via ffmpeg-devel
James Almer
Jan Ekström
Rémi Denis-Courmont
Anton Khirnov
Marvin Scholz
Brad Smith
Ramiro Polla
Matthieu Bouron
Stefan Oltmanns
Niklas Haas
Fei Wang
Zhao Zhili
Tong Wu
Dawid Kozinski
Gyan Doshi
Andreas Rheinhardt
Araz Iusubov
Thomas Siedel