Do not "think" will need 7.0.x (hard to tell what version is truly LTS
or needed for package support with ffmpeg), can always re-introduce it
as ffmpeg-compat:7 if we ever need it after ffmpeg-8.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Meant to be used with ffmpeg-compat.eclass, see its description.
4.4.5 likely won't see much use at this point if the ffmpeg-5
tracker is not missing anything, but adding anyway for now.
Note that this is not intended to provide libraries for old prebuilt
binaries, it is for building against using the eclass. If prebuilts
want to use this then they will likely need patchelf.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Semi-blind additions, decent deal of these are likely
obsolete, but will be review after old (non-compat)
versions been cleaned.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Both the slotting method and eclass are meant to be as simple
as possible, and isolated so that it does not really need to
work with everything given non-slotted ffmpeg stays.
Did not want turn ffmpeg into a permanent slotting model with
a FFMPEG_SLOT use_expand, eselect, or such potentially turning
it into a special Gentoo-only thing that often need hacks.
Essentially just a way for broken packages to gain time without
blocking everyone's ffmpeg updates.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Similar bare losing a few options, albeit given this version is for
compat and normal users do not need the full set of features (they
should use ffmpeg-6+), skip a few inconvenient IUSE/options:
- chromium: needs a different patch/logic it seems
- glslang: ffmpeg-4 did not have shaderc support, meaning that this
is the only alternative, but this breaks too easily
- mmal: was formerly kept due to lack of IUSE=soc, but would rather
not keep the raspberrypi-userland dependency forever
- npp: not tested, and doubt anyone would want this on anything but
latest ffmpeg (needs nvidia-cuda-toolkit)
- qsv: intelmedia-sdk is dead, and this version did not support libvpl
- amf: likely broken in this old version wrt bug #910271, assuming
newer 4.4.5 did not fix it, but even if it did still little reason
to support things like qsv/amf/nvenc as they are being left behind
in old versions
- soc: plus all its logic, never had a patch for this version anyway
- vmaf: seems broken with current libvmaf version wrt bug #931137,
and old libvmaf has some simd-related issues building (we *could*
patch ffmpeg but at this point I feel little reason to for ffmpeg-4).
- --enable-avresample (bug #722274): off by default, and gone
in later versions, no need to keep it enabled still
- --enable-lto: old version did not take =arg and, either way, keeping
it on this older codebase with a lot of asm just seem like trouble
More would likely fit that list, but not trying to overdo until
something actually causes a problem.
Would've wanted to drop USE=nvenc due to its dependency on old
nv-codec-headers but rather mask it not to have to update revdeps
that depend on nvenc over this.
Hopefully not overlooked anything relevant, spent less time on
this than ffmpeg-7 and "downgrading" an ebuild is awkward.
Ultimately this version is going to be short lived, there is almost
nothing left (that we package) that requires it.
Closes: https://bugs.gentoo.org/722274
Closes: https://bugs.gentoo.org/910271
Closes: https://bugs.gentoo.org/931137
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Almost identical, it only loses a few options compared to live
and need to bring back the __musl__ workaround.
Also switch to a patchset tarball, filesdir was large and would
not want to copy these to media-video/ffmpeg-compat as well.
Additionally include the texinfo-7.2 patch in it wrt bug #947707,
and the missing commit wrt bug #947605 (untested).
Hopefully not overlooked anything relevant, spent less time on
this than ffmpeg-7 and "downgrading" an ebuild is awkward.
Closes: https://bugs.gentoo.org/947605
Closes: https://bugs.gentoo.org/947707
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Using same as the new live ebuild bare for still having yasm
support, and not havng the vulkan-static option yet.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Adds IUSE="npp openmpt rabbitmq", mask where not keyworded (npp
can't gain more keywords, and the others kind of niche and not
really worth it).
soc mask is unneeded given 9999 no longer has the IUSE.
svg (rust) is due to no longer building with old librsvg, it *could*
be patched but this USE is not essential for the average user and
isn't worth maintaining.
There are a lot of pending cleanups due to removed IUSE, but that
has to wait until old versions removal.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Global description does not fit with the logic used here.
USE=openssl's description was also updated in a prior commit
to state that it disables gnutls (aka, it is now mentioned both
ways).
I considered inverting the logic, but felt that it would be worse
unless USE=openssl is the default (i.e. you go out of your way
to enable non-default USE=openssl but it does nothing as long as
gnutls is set). And then, I am not inclined to change the default
given issues like bug #905113 had.
If this continues to confuse users we could always give it up
and do a REQUIRED_USE, albeit it may annoy some users with
conflicts.
Closes: https://bugs.gentoo.org/905113
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Using "Enables" rather than "Enable" and full stops is unusual
as far as USE descriptions go. Wording may still not be best
and what I came up with may not necessarily be better in some
cases, but it should be a bit more consistent.
There is a few USE like hardcoded-tables or libxml2 that haven't
touched given they are due to be dropped after cleanup old ebuilds.
Not sure if the slot=0 bit was ever used? I've seen it got added a
few years ago but ffmpeg in the tree at the time didn't have other
slots to give it any meaning.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
This does not list all changes compared to original due to being
essentially a rewrite (not much sense in looking at the diff
given almost no lines in common), but to list or explain notable
ones:
* Cleanup a lot of obsolete logic, like mirror://gentoo snapshots,
SCM type, <openssl-3 handling, etc...
* Re-arrange IUSE=soc handling to drop the IUSE when FFMPEG_SOC_PATCH
is empty until maintainer of the patch has time to look at that
(easier to bump without it and removes the need to mask in 9999)
* Drop some IUSE, ffmpeg has a bit too many often confusing users and,
while debatable, some are not really useful to control bare at most
for expert user that could use EXTRA_ECONF if *really* wanted:
- debug (disabled): does very little beside override users' -g*,
albeit if want nasm debug symbols will need to set X86ASMFLAGS.
- encode (enabled): debated keeping it for disabling encoders
without their own USE for bit of size/build time reduction despite
no dependencies, but feel it is not really worth it as it
complicates the ebuild and can break expectations for a lot
of revdeps (many likely lack the [encode] that they need) --
removal also handles bug #770439
- fftools_* (disabled): almost no distros install these, many have
rather generic names, we were missing installing new ones,
upstream ffmpeg does not even have an install target for them,
and a global USE_EXPAND for this feels wasteful (*could* consider
adding a all-in-one IUSE=tools if some are wanted by users anyway
but let us try without and see if anyone complains)
- glslang (disabled): redundant with USE=shaderc and is a pain to
use directly given glslang often breaks things, esp. worse for
packages with a slow release cycle and old LTS versions like
ffmpeg (bug #918989, bug #920283, bug #922333, bug #922433) --
upstream also seems to favour shaderc: "libshaderc and libglslang
are mutually exclusive, if in doubt, disable libglslang"
(from ./configure)
- harcoded-tables (disabled): off by default upstream and listed as a
"experts only" option that seemingly provide little gains for a
notable size increase, do not believe it is worth exposing as a USE
- iconv (enabled): virtual/libiconv is essentially free anywhere but
prefix and disabling iconv can be rather broken for a few things
- network (enabled): no dependencies, fairly small, and many revdeps
likely expect it to be enabled and just missing the [network]
(tempting to do the same with USE=postproc but it would still be
conditional through USE=gpl and be more confusing, and then forcing
GPL also has its own issues)
- oss (auto): does not have a dedicated option and just checks
linux-headers and is very small, hardly anyone need this
but that argument could be applied to a *ton* of in/outdevs,
filters, de/encoders, and such and we would never see the end
of it
- pic (enabled): makes little sense not to enable nowadays and
handles bug #903754 + bug #916067 -- USE had the secondary
effect of disabling x86-32 asm which still doing given it is
difficult to support either way due to textrels and
>=binutils-2.41's enforcing (bug #916067, bug #920808), and
it is possibly broken for older hardware (bug #733556) -- as
a minor bonus, this should also let LTO work with abi_x86_32
(bug #654118)
- static-libs (disabled): cannot think of much of a use for this
esp. given how massive these libraries are and it would still
require to link with all its shared-only dependencies
- test (irrelevant): tests are not gone but there is no dependencies
(bc and wget are not needed) nor REQUIRED_USE to handle anymore,
thus USE is useless
- threads (auto): no real sense in disabling (bug #868471), and
leaving it auto let ffmpeg figure out the right implementation
to use which in most cases means default --enable-pthreads
- cpu_flags_* + cpudetection (enabled): tentatively anyway, just
let ffmpeg do its thing normally -- simplifies the ebuild a lot,
"should" fix bug #915384, and also handles whatever ebuild
was doing wrong wrt bug #752507 + bug #778035 (one minor "issue"
however is that all these flags being removed will leave users
confused as to what happened, if reading this and worried about
optimizations.. then no they are *not* disabled, and it is fine
for other machines thanks to detection at runtime)
* New IUSE:
- openmpt: requested in bug #921313
- npp: requested in bug #695210 -- note have not tested the
arm64 (sbsa) support, but it should work in theory as cuda
toolkit does install npp prebuilt arm64 libraries
- rabbitmq: trivial, may as well add support
(meant to add more but others did not fare as well and will leave
for later rather than during big changes, kept some minor notes in
the ebuild about things still not supported)
* Renamed IUSE:
- mp3->lame: this is only for encoding but it made it "sound"
needed for decoding (not the only case like this but this one
felt too generic), may surprise those that had it actually
enabled for encoding
- libxml2->xml and libdrm->drm: given newly enabling these by
default (see below), it's a good occasion to rename to the
more commonly used USE without causing issues
- libv4l->v4l: to be precise IUSE=v4l was removed and it gained
the meaning that IUSE=libv4l had -- old v4l is always enabled
(if linux) due to the hard dependency on linux-headers (see below)
-- given the old REQUIRED_USE with libv4l? ( v4l ), all users of
libv4l will have the new USE enabled already
- libdvdnav+libdvdread->dvd(combined): similar to mpv, simpler
for users when they just want dvds to work than worry about
each library (dvd support is new in ffmpeg-7, so this only
ever been masked)
* Enable a few extra IUSE by default that, while not everyone needs,
are useful and have dependencies that many users will already have.
- libass,truetype,fontconfig: for proper text/subtitles drawing
(kdenlive also wants [libass]), albeit video players tend to
have their own handling (that pull the same depdencies)
- drm: used in various pieces of code and little reason to
disable when mesa depends on libdrm either way
- xml: needed for DASH-type streams, notably used by youtube,
and about everyone has libxml2
(one downside of new defaults is MULTILIB_USEDEP, users that only
selectively enable abi_x86_32 rather than globally may be faced with
conflicts when updating)
* Always depend on linux-headers if linux, not *required* (except for
v4l) but this prevents a lot of automagic and going through alternate
code paths if missing (also go with >=6 which is needed for v4l2m2m
and I believe also USE=soc for v4l2request)
* Add missing vulkan-headers dependency wrt bug #865201, and also
opencl-headers wrt bug #941506 (not 100% sure that this is what
happened for the latter, but given binhost is setup it is likely).
* Bump nv-codec-headers min req to 12.1.14.0, while not *required*
it spares us for setting up ranges and 11.x is due for cleanup.
* Add missing x11-base/xorg-proto wrt bug #934196 -- technically
was longer an issue given libX11 RDEPENDs on it "now", but would
still rather keep these for now.
* Depend on >=librsvg-2.52 wrt bug #918613, USE=svg is not essential
for arches without rust and upstream bug been went 1.5 years without
activity.
* Update REQUIRED_USE a bit, cuda does not *need* nvenc (just get
one filter in less), libplacebo does nothing without sdl(ffplay)
or vulkan, and few others like these (likely still missing some).
* Drop musl HAVE_POSIX_IOCTL workaround, this is automatically set by
./configure since ffmpeg-7.1. However, note that there is another
related issue with libv4l (not v4l) that is not fixed (bug #911499).
* No longer ignore ffmpeg-spec-disposition test, fixed in 7.1.1.
* Fix verify-sig paths on prefix wrt bug #947253 (untested)
* No longer pass e.g. --disable-indev=alsa when already doing
--disable-alsa, ./configure seem to figure this out just fine.
* No longer pass --cpu, this expects the -march=<exact> reported by
the compiler or probes compiler with =native if =host), however it
does not account for -mno-* both passed or implied by =native and
could enable things it shouldn't. Furthermore, it adds -march=<exact>
after the users' -march=native (which is more correct, can enable
or disable additional features). This option only seem like trouble
and likely does not get tested much. Removing also handles
bug #830165 albeit ffmpeg-chromium is still affected.
* Replace EXTRA_FFMPEG_CONF by EXTRA_ECONF, while it is not using
econf nor autoconf, the latter is more widely known while the former
needs users to look at the ebuild -- also die if old variable is set
so users know about this change.
* Skip installing doc/*.txt, that seems mostly oriented at ffmpeg devs,
and feels noisy in the docdir, but do keep doc/APIChanges
* Replace all *GPL* by the + version given ./configure always output
with "or later" when listing the final license.
* Maybe not best way to go about this, but when doing incompatible
--enable-gpl --enable-nonfree, on top of the RESTRICT="bindist"
also add "all-rights-reserved" so a typical freedom ACCEPT_LICENSE
can block it.
* Rearrange chromium patch a bit to need less ebuild logic, and make
it unused for ffmpeg-compat.
* Drop EGIT_MIN_CLONE_TYPE, shallow clones seem fine now? If not,
could consider just using the official github mirror by default.
List of closed bugs may not be complete, plans are to recheck
still-open bugs after this is merged.
Bug: https://bugs.gentoo.org/830165
Closes: https://bugs.gentoo.org/654118
Closes: https://bugs.gentoo.org/695210
Closes: https://bugs.gentoo.org/733556
Closes: https://bugs.gentoo.org/752507
Closes: https://bugs.gentoo.org/770439
Closes: https://bugs.gentoo.org/778035
Closes: https://bugs.gentoo.org/865201
Closes: https://bugs.gentoo.org/868471
Closes: https://bugs.gentoo.org/903754
Closes: https://bugs.gentoo.org/915384
Closes: https://bugs.gentoo.org/916067
Closes: https://bugs.gentoo.org/918613
Closes: https://bugs.gentoo.org/918989
Closes: https://bugs.gentoo.org/920283
Closes: https://bugs.gentoo.org/920808
Closes: https://bugs.gentoo.org/921313
Closes: https://bugs.gentoo.org/922333
Closes: https://bugs.gentoo.org/922433
Closes: https://bugs.gentoo.org/934196
Closes: https://bugs.gentoo.org/941506
Closes: https://bugs.gentoo.org/947253
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Two versions to support the range of (not-masked) in-tree
nvidia-drivers and what older ffmpeg versions may require to work
(albeit unneededed right now, ffmpeg-6.1.1 is broken with 13.0
but that version is due for cleanup either way).
Add a pkg_postinst to inform of driver support, but do not reintroduce
a nvidia-drivers RDEPEND (leads to complications and this is supposed
to be headers-only, runtime is optional).
Also simplify the ebuild, the makefile's `all` target does nothing
but a sed (not worth a src_compile), and the unintuitive LIBDIR=share
installs to /usr/<libdir>/pkgconfig like the `mv` does.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
May as well take too, same pseudo-upstream as ffmpeg and it can
be sensitive to the versions sometimes requiring to set upper or
lower bounds.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Others are still welcome to work on this though, it's just that
media-video is mostly a placeholder project at this point and
hasn't touched ffmpeg in nearly 3 years.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Ionen Wolkens
Joel Anderson
Michał Górny
Valérian Rousset
idealseal
Sam James
Joe Kappus