While cl.exe supports -guard:signret, armasm64 complains about
unknown flag. Note that -guard:ehcont is accepted by armasm64.
Fixes:
error A2029: unknown command-line argument or argument value -guard:signret
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
In MSVC builds, object files built for shared or static libraries are
technically not compatible with each other. That's why building both
shared and static libraries simultaneously is not allowed in configure.
This may change in the future once dllimport/dllexport attributes are no
longer used. Which will be possible on next major bump. The only
remaining use of dllexport was changed in c6c8063186.
However, for test programs, we still build internal static libraries
that allow the test programs to access internal symbols.
In commit 8eca3fa619, I assumed that when
CONFIG_STATIC=0, we would never build a static library. We actually do
build one for internal purposes, for the test executables. In that case,
we only link the tested library statically (using the same object files
as built for the shared library), the rest of the libraries are still
linked dynamically.
Such libraries are never installed and are used only for test programs.
This change adds a -static suffix to these internal libraries to avoid
name conflicts. In the MSVC world, static libraries and import libraries
are generally the same thing and share the same naming conventions.
Fixes: 8eca3fa619
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
AVCodecParser has several fields which are not really meant
to be accessed by users, but it has no public-private
demarkation line, so these fields are technically public
and can therefore not simply be made private like
20f9727018 did for AVCodec.*
This commit therefore deprecates these fields and
schedules them to become private. All parsers have already
been switched to FFCodecParser, which (for now) is a union
of AVCodecParser and an unnamed clone of AVCodecParser
(new fields can be added at the end of this clone).
*: This is also the reason why split has never been removed despite
not being set for several years now.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a shader-based Apple ProRes decoder.
It supports all codec features for profiles up to
the 4444 XQ profile, ie.:
- 4:2:2 and 4:4:4 chroma subsampling
- 10- and 12-bit component depth
- Interlacing
- Alpha
The implementation consists in two shaders: the
VLD kernel does entropy decoding for color/alpha,
and the IDCT kernel performs the inverse transform
on color components.
Benchmarks for a 4k yuv422p10 sample:
- AMD Radeon 6700XT: 178 fps
- Intel i7 Tiger Lake: 37 fps
- NVidia Orin Nano: 70 fps
The drawvg filter can draw vector graphics on top of a video, using libcairo. It
is enabled if FFmpeg is configured with `--enable-cairo`.
The language for drawvg scripts is documented in `doc/drawvg-reference.texi`.
There are two new tests:
- `fate-filter-drawvg-interpreter` launch a script with most commands, and
verify which libcairo functions are executed.
- `fate-filter-drawvg-video` render a very simple image, just to verify that
libcairo is working as expected.
Signed-off-by: Ayose <ayosec@gmail.com>
The last 3dnow functions have been removed in commit
5ef613bcb0. So remove 3dnow
from configure; the only thing kept is that --disable-amd3dnow
is still accepted, but no longer advertised by --help.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use __MINGW_{PRINTF,SCANF}_FORMAT which matches the format check for
implementation that is actually used.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
It only needs it for some x86 fpel functions; instead
add a direct dependency for that.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The former is unnecessary since
3ceffe7839. The latter is since
ff_mpeg4_workaround_bugs() (and thereby setting the "old" qpeldsp
functions) has been moved inside #if CONFIG_MPEG4_DECODER.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This can be easily achieved by moving code only used by the MPEG-4
decoder behind #if CONFIG_MPEG4_DECODER.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Suppresses implicit integer conversion narrowing warnings:
warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
Those implicit conversions are abundant in ffmpeg's code base.
Additionally equivalent warnings are not enabled for GCC/Clang by
default, so they are mostly left unfixed.
Suppress reports about them to reduce noise in MSVC build log.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Only the mxpeg decoder uses it (and the reference/bitmask feature
of ff_mjpeg_decode_sos()). So only initialize it for mxpeg which
allows to remove the mjpeg->hpeldsp dependency.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes an issue uncovered since 0ce413af9c
where flags were properly separated but without the objcflags_filter
being initialized, if add_objcflags is called early as part of
add_allcflags, it would lead to the append() function using an empty
filter and trying to call the flag instead, leading to errors like:
./configure: line 976: -fsanitize=address: command not found
./configure: line 976: -fno-omit-frame-pointer: command not found
It was mistakenly removed in 0ce413af9c.
This matches how the Makefiles actually compile ObjC code, and
unlike C++, this seems to actually be benign and various existing
setups rely on that behaviour.
This was missed in 0ce413af9c.
This fixes proper detection of Objective C APIs (that are missing)
if targeting older macOS versions, such as the check for
AVCaptureSession.
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>
