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.
It reuses e.g. ff_put_pixels8_l2_8() directly even though
it never initializes a QpelDSPContext.
Fixes standalone compilation of the wmv2 encoder (the decoder
already has a qpeldsp dependency via the h263 decoder).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This adds the Linux-specific function call to detect CPU features. Unlike
the more portable auxillary vector, this supports extensions other than
single lettered ones. At this point, FFmpeg already needs this to detect
Zba and Zbb at run-time, and probably will need it for Zvbb in the near
future.
Support will be available in glibc 2.40 onward.
This version is seven years old, and present in Debian oldoldstable,
Ubuntu 20.04 and Leap 15.0.
Allows cleaning up the file substantially. In particular, this is
motivated by the desire to stop relying on init_static_data.
Some versions of xargs don't run any commands if no input is given,
others do run it at least once, causing errors.
Pass -r to xargs to avoid that behaviour and never run empty commands.
The extradata is generated by encoding a dummy frame, then reset
the encoder state by mediacodec flush(). It only works for pixel
format other than AV_PIX_FMT_MEDIACODEC, since I'm not sure how
to create a dummy frame safely with AV_PIX_FMT_MEDIACODEC.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
AImage_delete is introduced in API level 24, while AMediaFormat_new
is introduced in API level 21. We only need API level 21 to support
NDK mediacodec. This change doesn't break or change of
android_camera_indev since camera2ndk still needs API level 24.
Otherwise there are link errors:
LD ffprobe_g
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to
`ff_dovi_rpu_generate'
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to
`ff_dovi_configure'
collect2: error: ld returned 1 exit status
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
We need to set up the configuration struct appropriately based on the
codec type, colorspace metadata, and presence/absence of an EL (though,
we currently don't support an EL).
When present, we use the signalled RPU data header to help infer (and
validate) the right values.
Behavior can be controlled by a new DOVIContext.enable flag.
Note that the config.sh file is left without a shebang, this file is
supposed to be sourced into the current environment.
This commit is purely cosmetic.
Signed-off-by: J. Dekker <jdek@itanimul.li>
The preferred way to use LTO is --enable-lto but often times packagers
still end up with -flto in cflags for various reasons. Using grep
on binary object files is brittle and relies on specific object
representation, which in the case of LLVM bitcode, debug information or
other intermediary formats can fail silently.
This patch changes the check to a more commonly used define for GCC
style compilers. More checks may be needed to cover other potential
compilers that don't use the __BYTE_ORDER__ define.
Signed-off-by: J. Dekker <jdek@itanimul.li>
v2.0.0 is already four years old and even newer versions are available on
stable distro releases.
With this we stop setting codec capabilities during static data initialization.
Signed-off-by: James Almer <jamrial@gmail.com>
The LC3 audio codec is the default codec of Bluetooth LE audio.
This is a wrapper over the liblc3 library (https://github.com/google/liblc3).
Signed-off-by: Antoine Soulier <asoulier@google.com>
Since 591e27d1e7 they would
always be compiled even when nothing uses them; for shared
builds the default linker behaviour is to include them
even when not needed.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This change allows users to build libavfomat without support
for Immersive Audio Model by specifying --disable-iamf.
It helps to save on binary size in cases where it's important.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Eugene Zemtsov <eugene@chromium.org>
Signed-off-by: James Almer <jamrial@gmail.com>
C11 required to use ATOMIC_VAR_INIT to statically initialize
atomic objects with static storage duration. Yet this macro
was unsuitable for initializing structures [1] and was actually
unneeded for all known implementations (this includes our
compatibility fallback implementations which simply wrap the value
in parentheses: #define ATOMIC_VAR_INIT(value) (value)).
Therefore C17 deprecated the macro and C23 actually removed it [2].
Since commit 5ff0eb34d2 we default
to C17 if the compiler supports it; Clang warns about ATOMIC_VAR_INIT
in this mode. Given that no implementation ever needed this macro,
this commit stops using it to avoid this warning.
[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_485
[2]: https://en.cppreference.com/w/c/atomic/ATOMIC_VAR_INIT
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code relies on their presence and would presumably crash
when retrieving in_fmt->name if an encrypted stream with a codec id
without demuxer were encountered.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
C11 provides static assertions via _Static_assert and
provides static_assert as a convenience define for this
in assert.h. Our codebase uses the latter, as _Static_assert
has actually already been deprecated in C23.
Not all toolchains that declare support for C11 actually
support it; e.g. MSVC 19.27 does not support _Static_assert,
but somehow supports static_assert. MSVC 19.27 admits to be
a "preview implementation of the ISO C11 standard",
so this is not surprising (MSVC 19.28 does not come with
this caveat).
Furthermore some FATE boxes [1] use old GCC toolchains (with
only experimental support for C11) where _Static_assert is
supported, but assert.h does not provide the fallback define.
They are broken since the first usage of static_assert.
This commit therefore checks whether static_assert and
_Static_assert work with assert.h included; if not,
configure errors out.
This intentionally drops support for MSVC 19.27. Users like
the old FATE boxes above can still add -Dstatic_assert=_Static_assert
to cflags as a workaround if desired.
[1]: https://fate.ffmpeg.org/report.cgi?time=20240321123620&slot=sh4-debian-qemu-gcc-4.7
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodecContext extradata should be an AVCDecoderConfigurationRecord
when bitstream format is avcc. Simply concatenating the NALUs output
by x264_encoder_headers does not form a standard
AVCDecoderConfigurationRecord. The following cmd generates broken
file before the patch:
ffmpeg -i foo.mp4 -c:v libx264 -x264-params annexb=0 bar.mp4
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
While ensuring it's at least C11, the minimum supported version.
Also, enforce C11 on the host compiler, same as we already do for C11 on the
target compiler.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Both of these two structures were first available with X264_BUILD
163, so make relevant functionality conditional on the version
being at least such.
Keep handle_side_data available in all cases as this way X264_init
does not require additional version based conditions within it.
Finally, add a FATE test which verifies that pass-through of the
MDCV/CLL side data is working during encoding.
PyTorch is an open source machine learning framework that accelerates
the path from research prototyping to production deployment. Official
website: https://pytorch.org/. We call the C++ library of PyTorch as
LibTorch, the same below.
To build FFmpeg with LibTorch, please take following steps as
reference:
1. download LibTorch C++ library in
https://pytorch.org/get-started/locally/,
please select C++/Java for language, and other options as your need.
Please download cxx11 ABI version:
(libtorch-cxx11-abi-shared-with-deps-*.zip).
2. unzip the file to your own dir, with command
unzip libtorch-shared-with-deps-latest.zip -d your_dir
3. export libtorch_root/libtorch/include and
libtorch_root/libtorch/include/torch/csrc/api/include to $PATH
export libtorch_root/libtorch/lib/ to $LD_LIBRARY_PATH
4. config FFmpeg with ../configure --enable-libtorch \
--extra-cflag=-I/libtorch_root/libtorch/include \
--extra-cflag=-I/libtorch_root/libtorch/include/torch/csrc/api/include \
--extra-ldflags=-L/libtorch_root/libtorch/lib/
5. make
To run FFmpeg DNN inference with LibTorch backend:
./ffmpeg -i input.jpg -vf \
dnn_processing=dnn_backend=torch:model=LibTorch_model.pt -y output.jpg
The LibTorch_model.pt can be generated by Python with torch.jit.script()
api. https://pytorch.org/tutorials/advanced/cpp_export.html. This is
pytorch official guide about how to convert and load torchscript model.
Please note, torch.jit.trace() is not recommanded, since it does
not support ambiguous input size.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
All versions of MSVC that support C11 (namely >= v19.27)
also support the restrict keyword, therefore av_restrict
is no longer necessary since 75697836b1.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The samples I found all have 2000 sample packets, and by forcing the packet
size with a bsf we could automagically make muxing work for packets containing
more than 3640 samples.
Signed-off-by: Marton Balint <cus@passwd.hu>
