After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 789379 - wrong ffmpeg headers used during compilation
wrong ffmpeg headers used during compilation
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal normal
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-10-24 02:48 UTC by U. Artie Eoff
Modified: 2018-01-13 12:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix for internal ffmpeg include path ordering (2.36 KB, patch)
2017-10-24 02:50 UTC, U. Artie Eoff
committed Details | Review

Description U. Artie Eoff 2017-10-24 02:48:18 UTC
When user defines include path in CPPFLAGS and upstream ffmpeg is installed in that path, then gst-ffmpeg includes wrong ffmpeg header files for ext/libav plugin compilation when configured to use internal ffmpeg (i.e. it uses the headers from CPPFLAGS path).  As of today, the upstream ffmpeg headers are not compatible with gst-ffmpeg and this causes compilation failure.

The gcc command line that gets generated by autotools ends up like (assuming CPPFLAGS=-I/opt/local/include):

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I/opt/local/include -I ../../gst-libs/ext/libav -I ../../gst-libs/ext/libav -Wno-deprecated-declarations ...

Instead, it should be something like:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I ../../gst-libs/ext/libav -I ../../gst-libs/ext/libav -I/opt/local/include -Wno-deprecated-declarations
Comment 1 U. Artie Eoff 2017-10-24 02:50:09 UTC
Created attachment 362127 [details] [review]
Fix for internal ffmpeg include path ordering
Comment 2 Tim-Philipp Müller 2017-11-04 10:37:20 UTC
I guess it should do things differently depending on whether it is compiling against the internal gst-ffmpeg snapshot or an installed one?


> As of today, the upstream ffmpeg headers are not compatible
> with gst-ffmpeg and this causes compilation failure.

How do you mean? Our internal ffmpeg snapshot is 'upstream ffmpeg', no?
Comment 3 U. Artie Eoff 2017-11-04 15:03:50 UTC
(In reply to Tim-Philipp Müller from comment #2)
> I guess it should do things differently depending on whether it is compiling
> against the internal gst-ffmpeg snapshot or an installed one?
> 

Yes, it already does.  Except if you want to compile against internal snapshot, it doesn't work if you already have one installed.  That is what this bug is reporting.  And the patch fixes that.

> 
> > As of today, the upstream ffmpeg headers are not compatible
> > with gst-ffmpeg and this causes compilation failure.
> 
> How do you mean? Our internal ffmpeg snapshot is 'upstream ffmpeg', no?

Right.  But it's not always the latest.  At the time of writing, gst-ffmpeg did not compile against ffmpeg master ToT.
Comment 4 Tim-Philipp Müller 2018-01-13 12:19:53 UTC
Thanks for the patch!

commit 7a951369c7f7b3c16c4c4555e0df9f5ee693fc38 (HEAD -> master)
Author: U. Artie Eoff <ullysses.a.eoff@intel.com>
Date:   Mon Oct 23 19:35:31 2017 -0700

    libav: use LIBAV_CPPFLAGS for -I include paths
    
    Autotools automatically appends user CPPFLAGS after target
    CPPFLAGS.  Also, it puts all CPPFLAGS before CFLAGS in final
    generated gcc compile command.  The internal ffmpeg include
    paths need to come before any other external include paths
    to ensure we don't accidentally pickup external ffmpeg
    headers first (i.e. from user CPPFLAGS include paths).  Thus,
    move the internal LIBAV include paths to LIBAV_CPPFLAGS so
    that they come before any user defined CPPFLAGS.
    
    This allows ffmpeg and gst-ffmpeg to coexist on users system.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=789379