Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.
The min version requirement of 158 is applied for msvc builds only.
This is also removing the check for 'libx264 without pkg-config'
which was left for compatibility reasons about 7 years ago when
the pkg-config check was introduced by commit
e06263ef1e.
Co-authored-by: softworkz <softworkz@hotmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Allows non-UWP builds of FFmpeg with MediaFoundation to work on
N editions of Windows which are without MediaFoundation by default.
On UWP target, FFmpeg is linked directly against MediaFoundation since
LoadLibrary is not available.
This commit adresses https://trac.ffmpeg.org/ticket/9788
Signed-off-by: Martin Storsjö <martin@martin.st>
libmfx 1.28 was released 3 years ago, it is easy to get a greater
version than 1.28. We may remove lots of compile-time checks if adding
the requirement for the minimal version in the configure script.
Reviewed-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
AVIF Specification: https://aomediacodec.github.io/av1-avif
Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -still-picture 1 image.avif
Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif
We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).
The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
animated AVIF yet).
3) Verified to be valid by Compliance Warden:
https://github.com/gpac/ComplianceWarden
Fixes the encoder/muxer part of Trac Ticket #7621
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
sdl2 recently changed their versioning, moving the patch level to minor level
cd7c2f1de7
and have said that they will instead ship sdl3.pc for 3.0.0
Fixes ticket 9768
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
This filter is designed to parse embedded ICC profiles and attempt
extracting colorspace tags from them, updating the AVFrame metadata
accordingly.
This is intentionally made a separate filter, rather than being part of
libavcodec itself, so that it's an opt-in behavior for the time being.
This also gives the user more flexibility to e.g. first attach an ICC
profile and then also set the colorspace tags from it.
This makes #9673 possible, though not automatic.
Signed-off-by: Niklas Haas <git@haasn.dev>
This filter is designed to specifically cover the task of generating ICC
profiles (and attaching them to output frames) on demand. Other tasks,
such as ICC profile loading/stripping, or ICC profile application, are
better left to separate filters (or included into e.g. vf_setparams).
Signed-off-by: Niklas Haas <git@haasn.dev>
This introduces an optional dependency on lcms2 into FFmpeg. lcms2 is a
widely used library for ICC profile handling, which apart from being
used in almost all major image processing programs and video players,
has also been deployed in browsers. As such, it's both widely available
and well-tested.
Add a few helpers to cover our major use cases. This commit merely
introduces the helpers (and configure check), even though nothing uses
them yet.
It's worth pointing out that the reason the cmsToneCurves for each
AVCOL_TRC are cached inside the context, is because constructing a
cmsToneCurve requires evaluating the curve at 4096 (by default) grid
points and constructing a LUT. So, we ideally only want to do this once
per curve. This matters for e.g. ff_icc_profile_detect_transfer, which
essentially compares a profile against all of these generated LUTs.
Re-generating the LUTs for every iteration would be unnecessarily
wasteful.
The same consideration does not apply to e.g. cmsCreate*Profile, which
is a very lightweight operation just involving struct allocation and
setting a few pointers.
The cutoff value of 0.01 was determined by experimentation. The lowest
"false positive" delta I saw in practice was 0.13, and the largest
"false negative" delta was 0.0008. So a value of 0.01 sits comfortaby
almost exactly in the middle.
Signed-off-by: Niklas Haas <git@haasn.dev>
This patch adds support for:
- ffplay ipfs://<cid>
- ffplay ipns://<cid>
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a http:// url. This resulting url is
then handled by the http protocol. It could also be https
depending on the gateway provided.
To use this protocol, a gateway must be provided.
If you do nothing it will try to find it in your
$HOME/.ipfs/gateway file. The ways to set it manually are:
1. Define a -gateway <url> to the gateway.
2. Define $IPFS_GATEWAY with the full http link to the gateway.
3. Define $IPFS_PATH and point it to the IPFS data path.
4. Have IPFS running in your local user folder (under $HOME/.ipfs).
Signed-off-by: Mark Gaiser <markg85@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch is analogous to 20f9727018:
It hides the internal part of AVBitStreamFilter by adding a new
internal structure FFBitStreamFilter (declared in bsf_internal.h)
that has an AVBitStreamFilter as its first member; the internal
part of AVBitStreamFilter is moved to this new structure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The CRI decoder is useless without the MJPEG-decoder
(its init-function always errors out).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They return nicer error messages on error; furthermore,
they also use our allocation functions. It also stops
calling deflateEnd() on a z_stream that might not have been
successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They emit better error messages (it does not claim that inflateInit
failed upon an error from deflateInit!) and uses our allocation functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The rationale is the same as for the wrappers for inflateInit(),
although the case for it is admittedly not so strong because
there are less users of deflateInit().
Also remove an unnecessary inclusion of config.h in
libavformat/protocols.c in order to trigger a request for reconfigure
(which is needed for CONFIG_DEFLATE_WRAPPER to take effect).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead reuse and reset a single z_stream.
Also use FFZStream in decode_zbuf(), because it has nicer error
messages.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Returns better error messages in case of error and deduplicates
the inflateInit() code and also allows to cleanup generically
in case of errors as it is save to call ff_inflate_end() if
ff_inflate_init() has not been called successfully.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Returns better error messages in case of error and deduplicates
the inflateInit() code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Returns better error messages in case of error and deduplicates
the inflateInit() code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not documented to be safe to call inflateEnd() on a z_stream
that has never been successfully been initialized by inflateInit(),
but just zeroed. It just happens to work and several codecs rely
on this (they have FF_CODEC_CAP_INIT_CLEANUP set and even call
inflateEnd() when inflateInit() failed or has never been called).
To avoid this, other codecs recorded whether their zstream has been
initialized successfully or not.
This commit adds wrappers for inflateInit() and inflateEnd() that
do what these other codecs do; furthermore, they also take care of
properly setting up the zstream before inflateInit() and emit
an error message in case of error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
In Gentoo and ChromeOS we want to allow pure LLVM builds without
using GNU tools, so we block any unwanted mixed GNU/LLVM usages
(GNU tools are still kept around in our chroots for projects
like glibc which cannot yet be built otherwise).
The default ${cross_prefix}${ranlib_default} points to GNU and
fails, so move the test a bit later - after the defaults are
set and the proper values get overriden - such that ffmpeg
configure calls the llvm-ranlib we desire. [1]
[1] https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ffmpeg-4.4.1-r1.ebuild?id=7a34377e3277a6a0e2eedd40e90452a44c55f1e6#n477
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
The headers from version 3.7.1 are needed in order to support
parsing of frame properties. avs/version.h has been generated
as part of the AviSynth+ build process for a long time, but was
never installed with the includes until version 3.7.1a. Checking
for the presence of avs/version.h might have been sufficient,
but a version check mechanism might be useful in the future.
This does not change the version compatibility with the library
itself; previous 3.x versions of AviSynth+ as well as AviSynth 2.6
can still be used with the demuxer.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
