The implementation is based on:
https://learn.microsoft.com/en-us/windows/win32/medfound/direct3d-12-video-overview
With the Direct3D 12 video decoding support, we can render or process
the decoded images by the pixel shaders or compute shaders directly
without the extra copy overhead, which is beneficial especially if you
are trying to render or post-process a 4K or 8K video.
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua <toqsxw@outlook.com>
Signed-off-by: Tong Wu <tong1.wu@intel.com>
With the way the runtime checks are currently set up, every single
openh264 release, no matter how minor, is considered an ABI break and
requires ffmpeg recompilation. This is unnecessarily strict because it
doesn't allow downstream distributions to ship any openh264 bug fix
version updates without breaking ffmpeg's openh264 support.
Years ago, at the time when ffmpeg's openh264 support was merged,
openh264 releases were done without a versioned soname (the library was
just libopenh264.so, unversioned). Since then, starting with version
1.3.0, openh264 has started using versioned sonames and the intent has
been to bump the soname every time there's a new release with an ABI
change.
This patch drops the exact version check and instead adds a minimum
requirement on 1.3.0 to the configure script.
Signed-off-by: Kalev Lember <klember@redhat.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
It's available on macOS since 10.8, but not available on iOS until
16.0.
Reported and tested by xufuji456.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
libvpl deprecated some symbols (e.g. MFX_EXTBUFF_VPP_DENOISE2 is used to
replace MFX_EXTBUFF_VPP_DENOISE), however the new symbols aren't support
by MediaSDK runtime. In order to support the combination of libvpl and
MediaSDK runtime on legacy devices, we continue to use the deprecated
symbols in FFmpeg. This patch added -DMFX_DEPRECATED_OFF to CFLAGS to
silence the corresponding compilation warnings.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This is only supported at compilation time. If Zfhmin is supported, then
conversions are fast, which is what the flag is used for. At this time,
run-tiem detection is not possible, as in not supported by Linux. But even
if it were, the current FFmpeg approach seems unable to deal with it (same
problem as on x86, really).
This commit adds support for VP8 bitstream read methods to the cbs
codec. This enables the trace_headers bitstream filter to support VP8,
in addition to AV1, H.264, H.265, and VP9. This can be useful for
debugging VP8 stream issues.
The CBS VP8 implements a simple VP8 boolean decoder using GetBitContext
to read the bitstream.
Only the read methods `read_unit` and `split_fragment` are implemented.
The write methods `write_unit` and `assemble_fragment` return the error
code AVERROR_PATCHWELCOME. This is because CBS VP8 write is unlikely to
be used by any applications at the moment. The write methods can be
added later if there is a real need for them.
TESTS: ffmpeg -i fate-suite/vp8/frame_size_change.webm -vcodec copy
-bsf:v trace_headers -f null -
Signed-off-by: Jianhui Dai <jianhui.j.dai@intel.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Partially fixes ticket #798
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Peter Ross <pross@xvid.org>
The test can currently pass when _Pragma is not supported, since
_Pragma might be treated as a implicitly declared function.
This happens e.g. with tinycc.
Extending the check to 2 pragmas both matches the actual use
better and avoids this misdetection.
Clang versions before 17 (Xcode versions up to and including 15.0)
had a very annoying bug in its behaviour of the ".arch" directive
in assembly. If the directive only contained a level, such as
".arch armv8.2-a", it did validate the name of the level, but it
didn't apply the level to what instructions are allowed. The level
was applied if the directive contained an extra feature enabled,
such as ".arch armv8.2-a+crc" though. It was also applied on the
next ".arch_extension" directive.
This bug, combined with the fact that the same versions of Clang
didn't support the dotprod/i8mm extension names in either
".arch <level>+<feature>" or in ".arch_extension", could lead to
unexepcted build failures.
As the dotprod/i8mm extensions couldn't be enabled dynamically
via the ".arch_extension" directive, someone building ffmpeg could
try to enable them by configuring their build with
--extra-cflags="-march=armv8.6-a".
During configure, we test for support for the i8mm instructions
like this:
# Built with -march=armv8.6-a
.arch armv8.2-a # Has no visible effect here
#.arch_extension i8mm # Omitted as the extension name isn't known
usdot v0.4s, v0.16b, v0.16b
# Successfully assembled as armv8.6-a is the effective level,
# and i8mm is enabled implicitly in armv8.6-a.
Thus, we would enable assembling those instructions. However if
we later check for another extension, such as sve (which those
versions of Clang actually do support), we can later run into the
following situation when building actual code:
# Built with -march=armv8.6-a
.arch armv8.2-a # Has no visible effect here
#.arch_extension i8mm # Omitted as the extension name isn't known
.arch_extension sve # Included as "sve" is as supported extension name
# .arch_extension effectively activates the previous .arch directive,
# so the effective level is armv8.2-a+sve now.
usdot v0.4s, v0.16b, v0.16b
# Fails to build the instructions that require i8mm. Despite the
# configure check, the unrelated ".arch_extension sve" directive
# breaks the functionality of the i8mm feature.
This patch avoids this situation:
- By adding a dummy feature such as "+crc" on the .arch directive
(if supported), we make sure that it does get applied immediately,
avoiding it taking effect spuriously at a later unrelated
".arch_extension" directive.
- By checking for higher arch levels such as armv8.4-a and armv8.6-a,
we can assemble the dotprod and i8mm extensions without the user
needing to pass -march=armv8.6-a. This allows using the dotprod/i8mm
codepaths via runtime detection while keeping the binary runnable
on older versions. I.e. this enables the i8mm codepaths on Apple M2
machines while built with Xcode's Clang.
TL;DR: Enable the I8MM extensions for Apple M2 without the user needing
to do a custom configuration; avoid potential build breakage if a user
does such a custom configuration.
Once Xcode versions that have these issues fixed are prevalent, we
can consider reverting this change.
Signed-off-by: Martin Storsjö <martin@martin.st>
This patch adds two MSZ (Middle Size; half width) character
related options, mapping against newly added upstream
functionality:
* `replace_msz_japanese`, which was introduced in version 1.0.1
of libaribcaption.
* `replace_msz_glyph`, which was introduced in version 1.1.0
of libaribcaption.
The latter option improves bitmap type rendering if specified
fonts contain half-width glyphs (e.g., BIZ UDGothic), even
if both ASCII and Japanese MSZ replacement options are set
to false.
As these options require newer versions of libaribcaption, the
configure requirement has been bumped accordingly.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
At various points through the function librsvg_decode_frame, errors are
returned from immediately without deallocating any allocated structs.
This patch both fixes those leaks, and also fixes the use of functions
that are deprecated since librsvg version 2.52.0. The older calls are
still used, guarded by #ifdefs while the newer replacements are used if
librsvg >= 2.52.0. One of the deprecated functions is used as a check
for the configure shell script, so it was replaced with a different
function.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The libmfx deprecation warning tells you to build against libmfx 1.x,
but the actual solution is to use --enable-libvpl instead of using
--enable-libmfx. Update the warning message to reflect this.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
0cd8769207 utilized the rc_algorithm member of the kvz_config struct, which
was introduced in Kvazaar 2.0.0. This patch bumps the minimum version of
Kvazaar to 2.0.0 so that FFmpeg compiles successfully.
Signed-off-by: John Mather <johnmather@sidefx.com>
The custom-allocator logic has been completely defunct since a while,
since nothing depends on those targets, they never get used.
This updates jemalloc to pkg-config, adds the fallback option for
potential arbitrary allocators, and finally actually adds the libraries
to LDFLAGS.
They were replaced by TX from libavutil; the tremendous work
to get to this point (both creating TX as well as porting
the users of the components removed in this commit) was
completely performed by Lynne alone.
Removing the subsystems from configure may break some command lines,
because the --disable-fft etc. options are no longer recognized.
Co-authored-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVDCT API used by this filter does in no way depend
upon the FFT subsystem.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Keeping an ever growing list of CPUs just to pass -march to the compiler and
enable fast_cmov is a waste of time. Every CPU we know has limitations is
already handled here, so just fallback to enabling everything when a passed in
argument is not one of those.
This will enable optimizations for CPU architectures released in the past 7 or
so years with supported GCC and clang compilers when used as argument in
configure, instead of silently ignoring them.
Signed-off-by: James Almer <jamrial@gmail.com>
Avoid using the deprecated functions ssh_try_publickey_from_file among
others in favor of symbols introduced in libssh 0.6.0 (Jan 2014) and
update configure to require this version.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
OpenVINO API 2.0 was released in March 2022, which introduced new
features.
This commit implements current OpenVINO features with new 2.0 APIs. And
will add other features in API 2.0.
Please add installation path, which include openvino.pc, to
PKG_CONFIG_PATH mannually for new OpenVINO libs config.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
ddc1cd5cdd defined WIN32_LEAN_AND_MEAN
globally, which makes for much fewer transitive includes from
windows.h. With that define, CoTaskMemFree no longer gets
implicitly declared by just including windows.h, but one has to
include the right header objbase.h too.
That commit caused ole32 to no longer get detected, which caused
dxva2 to no longer be enabled. This gets fixed by this patch.
Signed-off-by: Martin Storsjö <martin@martin.st>
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit is the AVHWAccel analogue of commit
20f9727018: It moves the private fields
of AVHWAccel to a new struct FFHWAccel extending AVHWAccel
in an internal header (namely hwaccel_internal.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVISYNTH_INTERFACE_VERSION 10 fell in-between the releases of
3.7.2 and 3.7.3, and is required to be able to read the channel
layout information.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
av_random_bytes() can use OS provided strong random functions and does not
depend soley on openssl/gcrypt external libraries.
Fixes ticket #10441.
Signed-off-by: Marton Balint <cus@passwd.hu>
This is not actually used for anything. The configure check causes the
CPU feature flag to be set, but nothing consumes it at all.
While AArch64 does have VFP, it is only used for the scalar C code.
Conversely, it is still possible to disable VFP, by changing the
C compiler flags as before (though that only makes sense for an
hypothetical non-standard Armv8 platform without VFP).
Note that this retains the "vfp" option flag, for backward
compatibility and on the very remote but theoretically possible chance
that FFmpeg actually makes use of it in the future.
AV_CPU_FLAG_VFP is retained as it is actually used by AArch32.
libavutil/random_seed.c calls arc4random_buf which is
not available on OSX 10.4 Tiger, but the configuration
script tests for arc4random which is available.
Fix the configuration test to match the actual API used.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Add CodedBitstreamContext to parse VPS,SPS,PPS in VVC nal units.
Implement parsing and writing of SPS,PPS,VPS,PH,AUD,SEI and slices.
Add ff_cbs_type_h266 to cbs types tables and AV_CODEC_ID_H266
to cbs codec ids.
Co-authored-by: Thomas Siedel <thomas.ff@spin-digital.com>
Signed-off-by: James Almer <jamrial@gmail.com>
- text is now shaped using libharfbuz
- glyphs position is now accurate to 1/4 pixel in both directions
- the default line height is now the one defined in the font
Adds libharfbuzz dependency.
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
For now, there's not much value in this since Clang don't support
enabling the dotprod or i8mm features with either .arch_extension
or .arch (it has to be enabled by the base arch flags passed to
the compiler). But it may be supported in the future.
Signed-off-by: Martin Storsjö <martin@martin.st>
These are available since ARMv8.4-a and ARMv8.6-a respectively,
but can also be available optionally since ARMv8.2-a.
Check if ".arch armv8.2-a" and ".arch_extension {dotprod,i8mm}" are
supported, and check if the instructions can be assembled.
Current clang versions fail to support the dotprod and i8mm
features in the .arch_extension directive, but do support them
if enabled with -march=armv8.4-a on the command line. (Curiously,
lowering the arch level with ".arch armv8.2-a" doesn't make the
extensions unavailable if they were enabled with -march; if that
changes, Clang should also learn to support these extensions via
.arch_extension for them to remain usable here.)
Signed-off-by: Martin Storsjö <martin@martin.st>
This just bumps the required loader library version (libvulkan).
All device-related features, such as video decoding, atomics, etc.
are still optional and the code deals with their loss on a local level
(e.g. the decoder or filter checks for the features it needs, not
the hwcontext).
Bumping the required version essentially packs all maintenance
extensions which correct the spec rather than requiring to enable
them individually.
This patch will add MPEG4 encoder using Android Mediacodec
Signed-off-by: Samuel Mira <samuel.mira@qt.io<mailto:samuel.mira@qt.io>>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The only encoders avaliable using mediacodec were h264 and hevc. This
patch adds the vp9 encoder.
Signed-off-by: Samuel Mira <samuel.mira@qt.io<mailto:samuel.mira@qt.io>>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This patch add another ARIB caption decoder using libaribcaption
external library.
Unlike libaribb24, it supports 3 types of subtitle outputs:
* text: plain text
* ass: ASS formatted text
* bitmap: bitmap image
Default subtitle type is ass as same as libaribb24.
Advantages compared with libaribb24 on ASS subtitle are:
* Subtitle positioning.
* Multi-rect subtitle: some captions are displayed at different
position at a time.
* More stability and reproducibility.
To compile with this feature:
* libaribcaption external library has to be pre-installed.
https://github.com/xqq/libaribcaption
* configure with `--enable-libaribcaption` option.
`--enable-libaribb24` and `--enable-libaribcaption` options are
not exclusive. If both enabled, libaribcaption precedes as
order listed in `libavcodec/allcodecs.c`.
Signed-off-by: rcombs <rcombs@rcombs.me>
This allows users to specify an argument such as './configure
--enable-lto=thin' to use ThinLTO with Clang. The old functionality with
'./configure --enable-lto' is preserved.
Signed-off-by: J. Dekker <jdek@itanimul.li>
HLS segments may be MPEG-TS or fragmented MP4, so those (de)muxers are
required for reading/writing HLS media segments.
Fixes functionality with --disable-everything --enable-demuxer=hls
--enable-muxer=hls
This commit does for AVOutputFormat what commit
20f9727018 did for AVCodec:
It adds a new type FFOutputFormat, moves all the internals
of AVOutputFormat to it and adds a now reduced AVOutputFormat
as first member.
This does not affect/improve extensibility of both public
or private fields for muxers (it is still a mess due to lavd).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Like what we did for scale_qsv filter, we use QSVVPPContext as a base
context to manage MFX session for deinterlace_qsv filter.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Use QSVVPPContext as a base context of QSVScaleContext, hence we may
re-use functions defined for QSVVPPContext to manage MFX session for
scale_qsv filter.
In addition, system memory has been taken into account in
QSVVVPPContext, we may add support for non-QSV pixel formats in the
future.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
It is a URL rewriter for IPFS gateways, not an actual implementation of
IPFS, and naming it as such was both incorrect and misleading.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Currently, several components select atsc_a53, despite
not using anything from it themselves. They only select
it because parsing SEI messages adds an indirect dependency.
But using direct dependencies is more natural, so add
dedicated subsystems for them.
It already allows to remove a superfluous dependency of
the HEVC QSV encoder on hevc_sei and atsc_a53.
Adding new subsystems only becomes effective after a reconfiguration.
In order to force this, some needed headers (which are only included
implicitly before this commit) were included explicitly in
libavformat/allformats.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add qsv_transcode example which shows how to use qsv to do hardware
accelerated transcoding, also show how to dynamically set encoding
parameters.
examples:
Normal usage:
qsv_transcode input.mp4 h264_qsv output.mp4 "g 60"
Dynamic setting usage:
qsv_transcode input.mp4 hevc_qsv output.mp4 "g 60 asyne_depth 1"
100 "g 120"
This command initializes codec with gop_size 60 and change it to
120 after 100 frames
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
x265_sei is available since X265_BUILD 88. Bump required version
to 89 to fix the regression from commit 1f58503013, and remove a
conditional compilation.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
added a new option 'a53cc' (on by default, as in libx264) for rendering
AV_FRAME_DATA_A53_CC as hevc sei payloads.
the code is a blend of the libx265.c code for writing
AV_FRAME_DATA_SEI_UNREGISTERED with the libx264.c code for writing atsc
a/53 payloads.
It is the only encoder supporting quarter samples.
This also allows to remove the qpeldsp dependency from
mpegvideo_enc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only thing from the H.263 decoder that is reachable
by the VC-1 decoder is ff_h263_decode_init(); but it does
not even use all of it; e.g. h263dsp is unused and so are
the VLCs initialized in ff_h263_decode_init() (they amount
to about 77KB which are now no longer touched).
Notice that one could also call ff_idctdsp_init()
directly instead of ff_mpv_idct_init(); one could even
do so in ff_vc1_init_common().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only msmpeg4 code that is ever executed by the VC-1 based
decoders is ff_msmpeg4_decode_init() and what is directly
reachable from it. This is:
a) A call to av_image_check_size(), then ff_h263_decode_init(),
b) followed by setting [yc]_dc_scale_table and initializing
scantable/permutations.
c) Afterwards, some static tables are initialized.
d) Finally, slice_height is set.
The replacement for ff_msmpeg4_decode_init() performs a)
just like now; it also sets [yc]_dc_scale_table,
but it only initializes inter_scantable and intra_scantable
and not permutated_intra_[hv]_scantable: The latter are only
used inside decode_mb callbacks which are only called
in ff_h263_decode_frame() which is unused for VC-1.*
The static tables initialized in c) are not used at all by
VC-1 (the ones that are used have been factored out in
previous commits); this avoids touching 327KiB of .bss.
slice_height is also not used by the VC-1 decoder (setting
it in ff_msmpeg4_decode_init() is probably redundant after
b34397b4cd).
*: It follows from this that the VC-1 decoder is not really
based upon the H.263 decoder either; changing this will
be done in a future commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The encoder is fixed point, and uses an MDCT only for analysis. Due
to the slightly different rounding, the encoder makes a different
decision, so the tests have to be adjusted as well.
