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.
Introduced in 1992, the Alpha was a 64-bit RISC processor designed
to replace the VAX CISC machines sold by Digital Equipment Corporation.
After Digital was acquired by Compaq in 1998 -- who themselves would be
later purchased by Hewlett-Packard, the architecture was phased out over
the following decade. It became effectively defunct in 2007, the last
publicly available processor being the Alpha 21364.
FFmpeg has not added any DSP code for this architecture since lowres2
was introduced in 2012, and it is more than unlikely someone still wishes
to maintain it.
Remove the DSP and support code.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Support for SuperH was dropped over a decade ago. There no longer is any
architecture-specific code to be found, so just remove the corresponding
test. Technically it is still possible to compile FFmpeg as the
"generic" (pure C) architecture.
The DNN filters are useless without a backend.
This will also "fix" Coverity issues #1598288 and #1601718.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not all C run-times support this, and even then, it will be a while
before distributions provide recent enough versions thereof.
Since this is a trivial system call wrapper, we might just as well call
the corresponding kernel system call directly where the C run-time lacks
support but the kernel headers are new enough (as is the case on Debian
Unstable at the time of writing). In doing so, we need to add a few more
guards as the first suitable kernel (headers) release did not expose the
V, Zba and Zbb extensions.
Martin Storsjö
James Almer
Jan Ekström
Rémi Denis-Courmont
Anton Khirnov
Marvin Scholz
Lynne
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
Sean McGovern