Summary: | media-plugins/gst-plugins-libav-1.14.2 fails to build with >=media-video/ffmpeg-4: .../ext/libav/gstav.c:33:10: fatal error: libavfilter/avfiltergraph.h: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | GStreamer package maintainers <gstreamer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | althorion, blackrabbit, chris, ChrisArepantis, christophe.chabanois, dschridde+gentoobugs, josef64, krinpaus, marduk, mgorny, moiman, orzel, polynomial-c, poncho, softashell, steffen.weber, voron1, voyageur |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugzilla.gnome.org/show_bug.cgi?id=792900 https://github.com/gentoo/gentoo/pull/10341 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 655920 | ||
Bug Blocks: | 653678 | ||
Attachments: |
emerge-info.txt
emerge-history.txt environment etc.portage.tbz2 logs.tbz2 media-plugins:gst-plugins-libav-1.12.4:20180502-124739.log temp.tbz2 gst-plugins-libav-1.14.0-ffmpeg4.patch |
Description
Toralf Förster
2018-05-02 14:16:29 UTC
Created attachment 529392 [details]
emerge-info.txt
Created attachment 529394 [details]
emerge-history.txt
Created attachment 529396 [details]
environment
Created attachment 529398 [details]
etc.portage.tbz2
Created attachment 529400 [details]
logs.tbz2
Created attachment 529402 [details]
media-plugins:gst-plugins-libav-1.12.4:20180502-124739.log
Created attachment 529404 [details]
temp.tbz2
I found: https://gitlab.collabora.com/nicolas/gst-ffmpeg/commit/b529e05a6ad5a8226d2fcbdcc2cde1be09e5ecba.diff but there is tried a file not existing in gst-plugins-libav-1.12.4: --- * Applying ffmpeg4.patch ... The text leading up to this was: -------------------------- |diff --git a/ext/libav/gstavscale.c b/ext/libav/gstavscale.c |index f6d12ed..a6d6a18 100644 |--- a/ext/libav/gstavscale.c |+++ b/ext/libav/gstavscale.c -------------------------- No file to patch. Skipping patch. I guess above commint ist some work on the way to gst-plugins-libav-1.12.5 with ffmpeg-4 support upstream bug at: https://bugzilla.gnome.org/show_bug.cgi?id=792900 I successfully emerged with having ffmpeg-4 media-plugins/gst-plugins-libav-1.14.0 (from overlay github.com/heather/gentoo-gnome) Before emerge I applied the patch without the snipet of file a/ext/libav/gstavscale.c Created attachment 531918 [details, diff]
gst-plugins-libav-1.14.0-ffmpeg4.patch
I only deleted some little patching of a scale.c file which does not exist any more in sourche of gst-plugins-libav-1.14.0
Upstream 1.14.1 version does not work with ffmpeg either; it's specifically mentioned in release notes. There is an in-progress patch, but it's not yet ready and should not be grabbed into distros as of yet, I'm pretty sure. Why don't we have properly parallel installable ffmpeg with different sonames, at least when the major number changes, sigh... (In reply to Mart Raudsepp from comment #12) > Upstream 1.14.1 version does not work with ffmpeg either; it's specifically > mentioned in release notes. > There is an in-progress patch, but it's not yet ready and should not be > grabbed into distros as of yet, I'm pretty sure. > Why don't we have properly parallel installable ffmpeg with different > sonames, at least when the major number changes, sigh... As ffmpeg plays that role to _simple_ wrap all available and actual codecs I oppose the idea of complicating with having different sonames. Just because gstreamer is late with their coding? (And it is simple refactoring) Sadly this "in progress" patch actually is the only way to go along with ffmpeg-4 and having gstreamer. I didn't notice any hicups for now. Maybe the gstreamer ffmpeg apis are not used as much on my system ... Whatever you said doesn't justify ffmpeg not following basic SONAME standards, ABI handling and everything related to it. Especially when even going from ffmpeg-3 to ffmpeg-4, I can give some leeway to the smaller breakages in the different 3.x, but... Anyhow, I'm not including experimental patches not yet deemed OK by upstream. If something reaches gst-libav git master at least, feel free to notify here. (Maybe something is by now, can't check right this moment) didn't see any patches accepted to git yet, so the 1.14.1 gst-plugins-libav bump is without ffmpeg4 support for now (as far as I know, haven't tested) https://github.com/GStreamer/gst-libav/commit/8886a016fce625e1c25a4902be4021196a6784a2#diff-ff4e2dc4962dc25a1512353299992c8dR1400 Apparently won't be fixed befor 1.16. A known workaround is to enable USE=libav on gst-plugins-libav package. This essentially builds a bundled ffmpeg-3 and thus can co-exist with a system ffmpeg-4. If you decide to go that route, then please make sure to not keep it long term (e.g. apply it only for <media-plugins/gst-plugins-libav-1.15, so that 1.16 will automatically start using system ffmpeg again), and take note that it might be a bit outdated ffmpeg-3 series bundled version, thus may have some known security issues. System libav is not supported at all, despite the gstreamer package name, as libav is apparently in a sad state and no-one is keeping it working in the gstreamer plugin. 1.16 will support ffmpeg 4.0. Upstream says that release will hopefully be by end of year. Debian is using a 1.16 git snapshot to support ffmpeg 4.0, I suggest that we do the same. The ebuild should state that ffmpeg should be less than 4.0, it only states that it should be equal to or greater than 3.2.6: !libav? ( >=media-video/ffmpeg-3.2.6:0=[${MULTILIB_USEDEP}] ) If the ebuild was corrected an emerge @world would not try to install >=ffmpeg=4. Well, ffmpeg-4 shouldn't have been unmasked before; even with the dep change done, it'll be some fun blocking when you use an app that supports only ffmpeg-4, especially when ffmpeg-3 supporting versions get removed. But instead of waiting for the ffmpeg-4 compat review and unmasking then, ~arch was broken now instead. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df517a7d5553e3d853dd9bf3bfdca3eb0beda5a5 commit df517a7d5553e3d853dd9bf3bfdca3eb0beda5a5 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2018-11-06 21:34:49 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-11-06 21:37:05 +0000 media-plugins/gst-plugins-libav: reduce damage from uncoordinated ffmpeg-4 unmask by requiring <ffmpeg-4 Bug: https://bugs.gentoo.org/654628 Signed-off-by: Mart Raudsepp <leio@gentoo.org> Package-Manager: Portage-2.3.49, Repoman-2.3.11 media-plugins/gst-plugins-libav/gst-plugins-libav-1.14.1.ebuild | 6 ++++-- media-plugins/gst-plugins-libav/gst-plugins-libav-1.14.2.ebuild | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) Any ideas on when a version of media-plugins/gst-plugins-libav supporting ffmpeg 4 will be in Gentoo? I've had my PR out there for a week, maybe it would be helpful? https://github.com/gentoo/gentoo/pull/10341 Sorry, was too busy with council related discussions over weekend. Now I hope to get this settled by Wednesday or so, depending on work commitments. media-plugins/gst-plugins-libav requiring ffmpeg<4 totally breaks all updates on my systems. It creates blockers with other ffmpeg-dependant packages. Other packages can't be updated because emerge --keep-going is notoriously broken. Activating the libav use flag for <1.16 as suggested before is a viable workaround in this case, at least for the time being. I also agree with major ffmpeg version upgrades regularly breaking dependent packages is really awful and more often than not results in time-consuming tasks like searching for solutions and resolving conflicts. There are also other packages breaking, not only gstreamer. ok, i tried adding this to /etc/portage/package.use/ # https://bugs.gentoo.org/654628#c17 media-plugins/gst-plugins-libav libav but then media-plugins/gst-plugins-libav-1.14.2 fails to compile with errors like In file included from /usr/include/features.h:428:0, from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdint.h:26, from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/stdint.h:9, from src/libavutil/channel_layout.h:25, from src/libavformat/amr.c:29: /usr/include/bits/mathcalls.h:298:1: note: previous declaration of ‘round’ was here __MATHCALLX (round,, (_Mdouble_ __x), (__const__)); ^ In file included from src/libavutil/internal.h:169:0, from src/libavutil/common.h:467, from src/libavutil/avutil.h:296, from src/libavutil/samplefmt.h:24, from src/libavcodec/avcodec.h:31, from src/libavformat/avformat.h:319, from src/libavformat/amr.c:30: src/libavutil/libm.h:451:40: error: static declaration of ‘roundf’ follows non-static declaration static av_always_inline av_const float roundf(float x) ^~~~~~ In file included from src/libavutil/common.h:36:0, from src/libavutil/avutil.h:296, from src/libavutil/samplefmt.h:24, from src/libavcodec/avcodec.h:31, from src/libavformat/avformat.h:319, from src/libavformat/amr.c:30: /usr/include/bits/mathcalls.h:298:1: note: previous declaration of ‘roundf’ was here __MATHCALLX (round,, (_Mdouble_ __x), (__const__)); ^ The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cb222dd95881897798eb4d0e9f6de1b8625dddb2 commit cb222dd95881897798eb4d0e9f6de1b8625dddb2 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2018-11-25 23:13:44 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-11-25 23:23:13 +0000 media-plugins/gst-plugins-libav: add ffmpeg-4 compatibility patches, other tweaks * Pull a selective patchset from git master, that brings in ffmpeg-4 compatibility and some bug fixes; patchset tarball README has further details. * Add a debian-inspired patch to tell gstreamer registry that the libav plugin supported features may change, when the system ffmpeg library files change. This should hopefully ensure that gstreamer sees new codecs immediately after system-ffmpeg is recompiled to add them. Compared to Debian, we conditionalize it based on USE=libav, so it's only actually done if system-ffmpeg is used, as for us it's a choice, not always system-ffmpeg; this is achieved via #ifndef, thus no conditional patching. * Make bundled ffmpeg builds verbose for better build.log * Try harder to honor user choices for bundled ffmpeg builds with USE=libav by always disabling debug and passing CFLAGS as optflags; courtesy of Arfrever Frehtes Taifersar Arahesis Closes: https://bugs.gentoo.org/654628 Signed-off-by: Mart Raudsepp <leio@gentoo.org> Package-Manager: Portage-2.3.52, Repoman-2.3.11 media-plugins/gst-plugins-libav/Manifest | 2 + .../files/external-ffmpeg4-dep.patch | 20 ++++ .../gst-plugins-libav-1.14.4.4.1_p20181115.ebuild | 102 +++++++++++++++++++++ 3 files changed, 124 insertions(+) I confirm, it emerged fine here (with USE=-libav, the default) |