Bug 654628 – 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

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Toralf Förster 2018-05-02 14:16:29 UTC]

libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/portage/media-plugins/gst-plugins-libav-1.12.4/work/gst-libav-1.12.4/ext/libav -I../.. -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/var/tmp/portage/media-plugins/gst-plugins-libav-1.12.4/work/gst-libav-1.12.4/gst-libs -I../../gst-libs -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -Wall -Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wformat-nonliteral -Wformat-security -Wold-style-definition -Winit-self -Wmissing-include-dirs -Waddress -Waggregate-return -Wno-multichar -Wnested-externs -O2 -pipe -march=native -c /var/tmp/portage/media-plugins/gst-plugins-libav-1.12.4/work/gst-libav-1.12.4/ext/libav/gstav.c  -fPIC -DPIC -o .libs/libgstlibav_la-gstav.o
/var/tmp/portage/media-plugins/gst-plugins-libav-1.12.4/work/gst-libav-1.12.4/ext/libav/gstav.c:33:10: fatal error: libavfilter/avfiltergraph.h: No such file or directory
 #include <libavfilter/avfiltergraph.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

  -------------------------------------------------------------------

  This is an unstable amd64 chroot image at a tinderbox (==build bot)
  name: 17.0-desktop-plasma_ffmpeg4_20180501-112342

  -------------------------------------------------------------------

gcc-config -l:
 [1] x86_64-pc-linux-gnu-7.3.0 *

Available Python interpreters, in order of preference:
  [1]   python3.5
  [2]   python2.7 (fallback)




emerge -qpv media-plugins/gst-plugins-libav
[ebuild  N    ] media-plugins/gst-plugins-libav-1.12.4  USE="orc -libav" ABI_X86="(64) -32 (-x32)"

[Comment 1 Toralf Förster 2018-05-02 14:16:32 UTC]

Created attachment 529392 [details]
emerge-info.txt

[Comment 2 Toralf Förster 2018-05-02 14:16:35 UTC]

Created attachment 529394 [details]
emerge-history.txt

[Comment 3 Toralf Förster 2018-05-02 14:16:38 UTC]

Created attachment 529396 [details]
environment

[Comment 4 Toralf Förster 2018-05-02 14:16:41 UTC]

Created attachment 529398 [details]
etc.portage.tbz2

[Comment 5 Toralf Förster 2018-05-02 14:16:44 UTC]

Created attachment 529400 [details]
logs.tbz2

[Comment 6 Toralf Förster 2018-05-02 14:16:47 UTC]

Created attachment 529402 [details]
media-plugins:gst-plugins-libav-1.12.4:20180502-124739.log

[Comment 7 Toralf Förster 2018-05-02 14:16:50 UTC]

Created attachment 529404 [details]
temp.tbz2

[Comment 8 Ulenrich 2018-05-05 18:45:36 UTC]

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

[Comment 9 Ulenrich 2018-05-05 18:51:54 UTC]

upstream bug at: 
https://bugzilla.gnome.org/show_bug.cgi?id=792900

[Comment 10 Ulenrich 2018-05-17 13:10:49 UTC]

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

[Comment 11 Ulenrich 2018-05-17 13:14:42 UTC]

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

[Comment 12 Mart Raudsepp 2018-05-19 15:40:08 UTC]

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...

[Comment 13 Ulenrich 2018-05-23 11:43:57 UTC]

(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 ...

[Comment 14 Mart Raudsepp 2018-05-27 12:07:07 UTC]

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)

[Comment 15 Mart Raudsepp 2018-06-16 19:42:35 UTC]

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)

[Comment 16 Michał Górny 2018-07-28 08:59:38 UTC]

https://github.com/GStreamer/gst-libav/commit/8886a016fce625e1c25a4902be4021196a6784a2#diff-ff4e2dc4962dc25a1512353299992c8dR1400

Apparently won't be fixed befor 1.16.

[Comment 17 Mart Raudsepp 2018-10-04 21:28:59 UTC]

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.

[Comment 18 Craig Andrews 2018-11-05 19:36:45 UTC]

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.

[Comment 19 Chris Smith 2018-11-06 18:47:18 UTC]

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.

[Comment 20 Mart Raudsepp 2018-11-06 18:52:44 UTC]

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.

[Comment 21 Larry the Git Cow 2018-11-06 21:38:10 UTC]

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 <[e-mail]>
AuthorDate: 2018-11-06 21:34:49 +0000
Commit:     Mart Raudsepp <[e-mail]>
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 <[e-mail]>
    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(-)

[Comment 22 Craig Andrews 2018-11-12 03:42:23 UTC]

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

[Comment 23 Mart Raudsepp 2018-11-12 09:42:39 UTC]

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.

[Comment 24 Thomas Capricelli 2018-11-20 12:21:55 UTC]

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.

[Comment 25 Small_Penguin 2018-11-21 10:26:35 UTC]

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.

[Comment 26 Thomas Capricelli 2018-11-22 01:56:17 UTC]

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__));
 ^

[Comment 27 Larry the Git Cow 2018-11-25 23:24:35 UTC]

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 <[e-mail]>
AuthorDate: 2018-11-25 23:13:44 +0000
Commit:     Mart Raudsepp <[e-mail]>
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 <[e-mail]>
    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(+)

[Comment 28 Thomas Capricelli 2018-11-26 21:33:13 UTC]

I confirm, it emerged fine here (with USE=-libav, the default)