MinGWs ANSI stdio is quite slow, and when using UCRT, its extra features
are not needed.
The only troublesome part with ucrt printf is that is disagrees about
the size of "long double", but FFmpeg does not use that anywhere, let
alone prints it.
Right now, CFLAGS like -std=c17 leak onto the C++ compilers commandline,
leading to tons of warnings and even some errors.
Undefining __STRICT_ANSI__ causes strong warnings from the stdlib
headers. So only set it for C.
This version check for whip is unnecessary.
Since several rencet patches to the configure
have already added version checks for OpenSSL.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
This amends 307983b292 to fix
building with older versions of mingw-w64.
The previously checked constant, SP_PROT_DTLS1_X_CLIENT, was
added in mingw-w64 in df36f5deda23192d0ee99ffd661ea36df924e667
in 2020, and is included in released versions since v8.0.0.
The new checked constant SECPKG_ATTR_DTLS_MTU was added in
mingw-w64 in 0792283787cca8fc27dd38671107c791c87f4db3 in 2021,
and first appeared in mingw-w64 v9.0.0.
This fixes building with mingw-w64 v8, which is the version bundled
in Ubuntu 22.04.
A --enable-* option should not have a condition where it's enabled by some
other mean, as is the case here if swscale is enabled.
Signed-off-by: James Almer <jamrial@gmail.com>
The project introduced API breaking changes to some of their public functions,
and given the library is relatively new, just bump the minimum supported
version instead of adding ifdeffery to the source files.
Signed-off-by: James Almer <jamrial@gmail.com>
av_exif_* functions are part of libavcodec's public API since
ad77345a5d, so the EXIF objects can't
be disabled.
Fixes compilation with --disable-everything.
Commit f256487cd8 bumped requirement to
1.1.0 for OPENSSL_init_ssl.
Bump this again to 1.1.1, because it was an LTS version. Although it has
no mainline support anymore, it still has paid/premium support. 1.1.0 has
no support at all.
Motivated for use of BIO_read_ex() for next commits.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
On Windows, static libraries are typically named with a .lib extension.
An exception to this is MinGW targets, which are treated as a distinct
target-os.
Using Windows-style naming allows `clang` to be used as the linker
driver, instead of invoking link or lld-link directly. The latter
approach requires manually specifying standard libraries when compiling
with `clang` rather than `clang-cl`, and manually specifying standard
libraries may be error-prone or incomplete.
Using Windows-style naming allows Clang to be used as the linker driver,
instead of invoking link or lld-link directly. The latter approach
requires manually specifying standard libraries, which may be
error-prone or incomplete.
This change also improves support for LTO and sanitizer builds, where
it's significantly easier to let the compiler driver manage the
necessary linker flags.
It fixes issues where Clang is asked to link `-lavcodec`, which gets
passed to the linker as avcodec.lib, resulting in an error like:
lld-link: error: could not open 'avcodec.lib': no such file or directory
This happens because `libavcodec.a` was unexpectedly generated, not
`avcodec.lib` expected by tooling.
Additionally, using `clang` (not `clang-cl`) is simplified, as it does
not use autolinking like MSVC/clang-cl does. Now `--ld=clang` can be
used to add all the required libraries. Previously, building with
`clang` was only possible by using `--ld=lld-link` and manually
specifying system dependencies in `extra-ldflags`.
Note that those changes doesn't affect mingw build. MSVC builds will
produce .lib static libraries now, but the linking process itself is not
affected, because filenames are passed directly.
To summarize in Windows non-mingw builds:
Static builds now produce `lib/avcodec.lib` instead of `lib/libavcodec.a`.
Shared builds remain unchanged, producing `bin/avcodec.lib` together with
`bin/avcodec-62.dll`.
This also removes setting LD_LIB from Win32/64 target as there is one
type of .lib in practice. We cannot build both shared and static at the
same time as noted by the next line.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This commit adds a ProRes RAW hardware implementation written in Vulkan.
Both version 0 and version 1 streams are supported.
The implementation is highly parallelized, with 512 invocations dispatched
per every tile, with generally 4k tiles on a 5.8k stream.
Thanks to unlord for the 8-point iDCT.
Benchmark for a generic 5.8k RAW HQ file:
6900XT: 63fps
7900XTX: 84fps
6000 Ada: 120fps
Intel: 9fps
This changes configure to stop disabling -ftree-vectorize on
GCC versions 13 and newer, on major architectures.
Background:
- Original `-fno-tree-vectorize` was added in 2009 in commit
973859f523 to avoid compiler errors.
- Re-enabled in 2016 in commit cb8646af24 but caused failures due
to inline CABAC assembly issues and was disabled again in
fd6dbc5385.
- Commit 182663a58a in 2023 fixed the inline CABAC assembly issues.
- Recent versions of GCC, in particular 13 and newer, seem to
generally work reliably with respect to vectorization, although bugs
have been observed on Loongarch.
Cautiously allow the GCC default of having vectorization enabled,
on major architectures where we expect to see enough testing. If
further issues are observed, they should be reported and noted here in
configure, so the workarounds can be scoped and version limited.
This is important for feature checking to work correctly.
It can happen that an unrecognized flag passes the compile test with
only a warning, while failing in preprocessor-only check with an error.
This causes all test_cpp calls to fail and silently produces arguably
broken MSVC builds. Also, all check_* functions don't work as expected,
because they assume the check passed, even though there was a warning.
Additionally, this brings the behavior in line with GCC/Clang based
builds, failing early on unrecognized flags instead of silently
continuing with warnings in the log.
The /options:strict option is available starting in Visual Studio 2022
version 17.0. Because of that, we cannot use check_cflags alone, as it
would add this flag for older MSVC versions and produce warnings. So, we
need to manually perform a version check. A bit of a chicken and egg
problem.
Perform the version check before adding extra flags from the user to
ensure we don't silently fail the preprocessor check due to invalid
flags on older MSVC versions. Note that behavior differs depending on
whether we are compiling or only preprocessing.
This fixes silent different between handling:
`cl.exe -P foo c.c`
c1: fatal error C1083: Cannot open source file: 'foo': No such file
or directory
`cl.exe -c foo c.c`
cl : Command line warning D9024 : unrecognized source file type
'foo', object file assumed
Where -P fails, while -c throws warnings only. Of course `foo` is
completely bogus here, but depends on the flags or configuration this
may be unsupported argument. Or even some converted path from MSYS when
run inside it. The objective is to always error out instead of silently
hiding this.
Use check_cflags even after the _MSC_FULL_VER check, for non-MSVC
compilers. For example Clang-CL impersonate MSVC, but does not support
-options:strict flag currently.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This avoids adding flags that cl.exe doesn't understand.
Fixes cases where external libraries pkg-config file adds `-L` to the
cflags, strip it before passing to cl.exe.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
There was implicit assumption that the $TMPC file is empty when doing
--cpu=host checks. This breaks if any check is done before that.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This commit introduces a new hardware-accelerated video filter, scale_d3d11,
which performs scaling and format conversion using Direct3D 11. The filter enables
efficient GPU-based scaling and pixel format conversion (p010 to nv12), reducing
CPU overhead and latency in video pipelines.
In OSS-Fuzz build environment flags are handled by CFLAGS and LDFLAGS.
In local build use --toolchain=clang-fuzz-asan-ubsan or similar
combination depending on requested sanitizers.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
It's possible to call linker indirectly through driver like Clang. In
which cases linker args has to be prefixed with -Wl.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Old Mingw-w64 releases provided by some distros seemingly don't have them, so
check for them and disable the dtls protocol if unavailable.
Signed-off-by: James Almer <jamrial@gmail.com>
