Name the feature "arm_crc" rather than plain "crc", to make it
clear that this is about a CPU feature extension, not CRC
implementations in general.
This requires dealing with the extension slightly differently
than other extensions, as the name of the feature and the
".arch_extension" extension name differ.
Naming it with an "arm" prefix rather than "aarch64", as the
CPU extension also is available in 32 bit ARM form, even though
we don't intend to use it there.
This allows naming the ffmpeg wide feature with a different (more
elaborate) name than the raw cpu extension as it is spelled in
the ".arch_extension" directives.
We use a dummy aarch64 feature to work around an issue in older
Clang, where an .arch line such as ".arch armv8.2-a" doesn't take
effect immediately, while one like ".arch armv8.2-a+feature" works.
Previously, we used "crc" for this dummy feature to add (as an
old feature that would be supported widely by old toolchains).
But as we may want to actually use crc features and detect whether
they are supported, we may want to switch to another feature.
Use the "fp" feature instead, for the purposes of this extra
feature in the .arch lines. (The "fp" feature indicates floating
point support, which is implicitly part of the baseline feature
set anyway.)
They are only used by the decoder (which has them twice, because
the IntraX8Context contains a WMV2DSPContext whose put_mspel_pixels
functions were unused), so move them there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
By default, the D3D12 video encoder uses MAXIMUM, which means no restriction—it uses the highest precision supported by the driver.
Applications may want to reduce precision to improve speed or reduce power consumption. This requires the encoder to support user-defined motion estimation precision modes.
D3D12_VIDEO_ENCODER_MOTION_ESTIMATION_PRECISION_MODE defines several precision modes:
maximum: No restriction, uses the maximum precision supported by the driver.
full_pixel: Allows only full-pixel precision.
half_pixel: Allows half-pixel precision.
quarter-pixel: Allows quarter-pixel precision.
eighth-pixel: Allows eighth-pixel precision (introduced in Windows 11).
Sample Command Line:
ffmpeg -hwaccel d3d12va -hwaccel_output_format d3d12 -extra_hw_frames 20 -i input.mp4 -an -c:v h264_d3d12va -me_precision half_pixel out.mp4
Busybox-w32 [1] works for building ffmpeg on Windows (as an
alternative to msys2, cygwin or WSL).
On busybox-w32, "uname" returns "Windows_NT"; recognize this
in exesuf() as having an .exe suffix.
If building in this environment with a mingw toolchain, one has
to explicitly set --target-os=mingw32. (We probably don't
want to imply that this uname, set as target_os_default, would
default to mingw?) But despite what is set with --target-os,
one can't override the configure variable "host_os", which
exesuf() has to recognize.
[1] https://github.com/rmyorston/busybox-w32
When building DLLs on ARM64EC, the default use of `dumpbin
-linkermember:1` fails because ARM64EC static libraries use a
different linker member format. Use `-linkermember:32` for ARM64EC
to correctly extract symbols.
Additionally, MSVC inserts $exit_thunk and $entry_thunk symbols
for ARM64EC to handle x64 ↔ ARM64 transitions. These are internal
thunks and must not be exported. Filter them out when generating
the .def file to avoid unresolved symbols or invalid exports.
Trim out the leading '#' on ARM64EC function symbols. This is only
relevant on ARM64EC, but it is benign to do that filtering on
all architectures (such symbols aren't expected on other
architectures).
Simplify the sed command by removing the symbol address with a
sed expression instead of a later "cut" command.
This ensures correct symbol extraction and stable DLL generation
on ARM64EC targets, while keeping behavior unchanged for other
Windows architectures.
Older versions of Clang (Xcode 14, llvm.org Clang 13 and 14)
do support and recognize SME, but when enabled through
".arch_extension sme" it fails to transitively enable support
for Streaming SVE; this was fixed in [1].
This issue results in those versions currently detecting support
for SME, but later failing to build cpu_sme.s with errors like
"error: instruction requires: sve or sme" or "error: instruction
requires: streaming-sve or sve", on the "cntb x0" instruction.
Extend the check for this instruction set extension, to test
with two instructions, both specifically a SME instruction
(smstart) and an instruction that is available in Streaming SVE
mode (cntb).
For the configure check, add an extra parameter to
check_archext_insn for an optional second instruction to check.
It would be tempting to just pass both instructions through
the same parameter, as "smstart; cntb x0". However, Darwin
targets use a different token (%%) for starting a new
instruction on the same line - those targets interpret ";"
as the start of a comment. Due to that, such a check would
entirely ignore the second instruction on Darwin targets.
To avoid dealing with the variability in passing multiple
instructions on one line, just pass the optional second
instruction on a separate line.
[1] ff3f3a54e2
_cflags_noopt was previously set to optimize for size as a workaround
for issues in MSVC builds without any optimizations. Specifically the
lack of DCE and constant merging. This is no longer needed, as those
issues have been fixed in our codebase.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Intra refresh is a technique that gradually refreshes the video by encoding rows or regions as intra macroblocks/CTUs spread over multiple frames, rather than using periodic I-frames.
This provides better error resilience for video streaming while maintaining more consistent bitrate.
Disable Intra Refresh (This is the default)
ffmpeg -init_hw_device d3d12va -hwaccel d3d12va -hwaccel_output_format d3d12 \
-i input.mp4 \
-c:v h264_d3d12va \
-intra_refresh_mode none \
-intra_refresh_duration 30 \
-g 60 \
output.h264
Enable Intra Refresh
ffmpeg -init_hw_device d3d12va -hwaccel d3d12va -hwaccel_output_format d3d12 \
-i input.mp4 \
-c:v h264_d3d12va \
-intra_refresh_mode row_based \
-intra_refresh_duration 30 \
-g 60 \
output.h264
Parameters
- `-intra_refresh_mode`: Set to `row_based` to enable row-based intra refresh, or `NONE` to disable
- `-intra_refresh_duration`: Number of frames over which to spread the intra refresh (default: 0 = use GOP size)
- `-g`: GOP size (should typically be larger than intra refresh duration)
Playback to a decklink device with a newer version of the
DeckLink SDK (14.3) stalls because the driver code calls
IDeckLinkVideoFrame::QueryInterface, which is not
implemented by ffmpeg.
This patch implements decklink_frame::QueryInterface,
so that playback works with both older (12.x) and
newer (>= 14.3) drivers.
Note: The patch still does not allow the code to compile
with DeckLink SDK 14.3 or newer, as the API has changed.
Fix#20571
Avoid build errors with openssl forks (like libressl)
that lack some APIs.
This patch replace header check for OPENSSL_init_ssl
(was added in 1.1.0) with the OpenSSL 1.1.1 new API
DTLS_get_data_mtu.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
Red Hat Enterprise Linux 9 is one patch version lower than what
FFmpeg currently requests. The slightly older versions still result
in a working build of FFmpeg with DVD support, so allow those
versions to be consumed to build FFmpeg.
Signed-off-by: Neal Gompa <neal@gompa.dev>
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>
