gst-ffmpeg is broken since the libav-9 introduction

gst-ffmpeg is broken since the libav-9 introduction

[Mike Looijmans]

Commit 4ceff7d0a1f28eb1ce5d288111015bff8d5e9a7e "libav: drop older 0.8.* 
and use libav-9 by default" removed libav 0.8 in favor of the "9" 
edition. However, after compiling this for a MIPS box, the gst-ffmpeg 
plugin now refuses to load and displays the following at runtime:

(gst-plugin-scanner:971): GStreamer-WARNING **: Failed to load plugin 
'/usr/lib/gstreamer-0.10/libgstffmpeg.so': 
/usr/lib/gstreamer-0.10/libgstffmpeg.so: undefined symbol: 
avcodec_get_context_defaults

The "avcodec_get_context_defaults" method is mentioned even in 
libav-9.patch.

Reverting to the 0.8 version "resolves" it.

I wonder if we're the only ones getting this?

-- 
Mike Looijmans

Re: gst-ffmpeg is broken since the libav-9 introduction

[Gary Thomas]

On 2015-03-06 10:51, Mike Looijmans wrote:
> Commit 4ceff7d0a1f28eb1ce5d288111015bff8d5e9a7e "libav: drop older 0.8.* and use libav-9 by default" removed libav 0.8 in favor of the "9" edition. However, after compiling this
> for a MIPS box, the gst-ffmpeg plugin now refuses to load and displays the following at runtime:
>
> (gst-plugin-scanner:971): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /usr/lib/gstreamer-0.10/libgstffmpeg.so: undefined symbol:
> avcodec_get_context_defaults
>
> The "avcodec_get_context_defaults" method is mentioned even in libav-9.patch.
>
> Reverting to the 0.8 version "resolves" it.
>
> I wonder if we're the only ones getting this?
>

I get a different error, but surely just as deadly since it
fails to register the whole ffmpeg plugin:
(gst-plugin-scanner:1108): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /usr/li
b/gstreamer-0.10/libgstffmpeg.so: undefined symbol: av_get_bits_per_sample_format
(gst-plugin-scanner:1108): GLib-GObject-WARNING **: cannot register existing type 'GstVorbisDec'

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: gst-ffmpeg is broken since the libav-9 introduction

[Gary Thomas]

On 2015-03-06 12:54, Gary Thomas wrote:
> On 2015-03-06 10:51, Mike Looijmans wrote:
>> Commit 4ceff7d0a1f28eb1ce5d288111015bff8d5e9a7e "libav: drop older 0.8.* and use libav-9 by default" removed libav 0.8 in favor of the "9" edition. However, after compiling this
>> for a MIPS box, the gst-ffmpeg plugin now refuses to load and displays the following at runtime:
>>
>> (gst-plugin-scanner:971): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /usr/lib/gstreamer-0.10/libgstffmpeg.so: undefined symbol:
>> avcodec_get_context_defaults
>>
>> The "avcodec_get_context_defaults" method is mentioned even in libav-9.patch.
>>
>> Reverting to the 0.8 version "resolves" it.
>>
>> I wonder if we're the only ones getting this?
>>
>
> I get a different error, but surely just as deadly since it
> fails to register the whole ffmpeg plugin:
> (gst-plugin-scanner:1108): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /usr/li
> b/gstreamer-0.10/libgstffmpeg.so: undefined symbol: av_get_bits_per_sample_format
> (gst-plugin-scanner:1108): GLib-GObject-WARNING **: cannot register existing type 'GstVorbisDec'
>

Submitted as bug #7425

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: gst-ffmpeg is broken since the libav-9 introduction

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On 6 March 2015 at 17:51, Mike Looijmans <mike.looijmans@topic.nl> wrote:

> Commit 4ceff7d0a1f28eb1ce5d288111015bff8d5e9a7e "libav: drop older 0.8.*
> and use libav-9 by default" removed libav 0.8 in favor of the "9" edition.
> However, after compiling this for a MIPS box, the gst-ffmpeg plugin now
> refuses to load and displays the following at runtime:
>

Hm, bad testing, sorry.  This would be why gstreamer-libav 1.0 defaults to
using it's own internal copy of libav then. :/

I see that gstreamer-ffmpeg_0.10 defaults to using the internal libav, and
as the API clearly changed we need to do that.  Can you verify that
removing external-libav from the PACKAGECONFIG fixes this problem?

Ross

[-- Attachment #2: Type: text/html, Size: 1205 bytes --]

Re: gst-ffmpeg is broken since the libav-9 introduction

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

Oh and FWIW the Sato images in master just flipped from GStreamer 0.10 to
1.4 by default, so I do hope that GStreamer 0.10 will disappear from
oe-core after the next release (moving to meta-multimedia).

Can I ask why you're still using GStreamer 0.10?  If there's a good reason
to keep 0.10 in oe-core during the next cycle we can, but otherwise the
sooner it can be removed entirely as it's no longer tested the better.

Ross

On 9 March 2015 at 15:24, Burton, Ross <ross.burton@intel.com> wrote:

>
> On 6 March 2015 at 17:51, Mike Looijmans <mike.looijmans@topic.nl> wrote:
>
>> Commit 4ceff7d0a1f28eb1ce5d288111015bff8d5e9a7e "libav: drop older 0.8.*
>> and use libav-9 by default" removed libav 0.8 in favor of the "9" edition.
>> However, after compiling this for a MIPS box, the gst-ffmpeg plugin now
>> refuses to load and displays the following at runtime:
>>
>
> Hm, bad testing, sorry.  This would be why gstreamer-libav 1.0 defaults to
> using it's own internal copy of libav then. :/
>
> I see that gstreamer-ffmpeg_0.10 defaults to using the internal libav, and
> as the API clearly changed we need to do that.  Can you verify that
> removing external-libav from the PACKAGECONFIG fixes this problem?
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 2119 bytes --]

Re: gst-ffmpeg is broken since the libav-9 introduction

[Mike Looijmans]

On 09-03-15 16:26, Burton, Ross wrote:
> Oh and FWIW the Sato images in master just flipped from GStreamer 0.10
> to 1.4 by default, so I do hope that GStreamer 0.10 will disappear from
> oe-core after the next release (moving to meta-multimedia).
>
> Can I ask why you're still using GStreamer 0.10?  If there's a good
> reason to keep 0.10 in oe-core during the next cycle we can, but
> otherwise the sooner it can be removed entirely as it's no longer tested
> the better.

It works, and we're stuck with vendors providing no support for 1.x, and 
we've been trying to get the 1.x version integrated but that's a rather 
big task and the total lack of decent "how to migrate from 0.1 to 1.x" 
guides isn't doing much to speed that up either.

The current situation is so bad (and has been for many years) that we 
have our own copies of the gstreamer 0.1 recipes in OpenPLi.


> Ross
>
> On 9 March 2015 at 15:24, Burton, Ross <ross.burton@intel.com
> <mailto:ross.burton@intel.com>> wrote:
>
>
>     On 6 March 2015 at 17:51, Mike Looijmans <mike.looijmans@topic.nl
>     <mailto:mike.looijmans@topic.nl>> wrote:
>
>         Commit 4ceff7d0a1f28eb1ce5d288111015b__ff8d5e9a7e "libav: drop
>         older 0.8.* and use libav-9 by default" removed libav 0.8 in
>         favor of the "9" edition. However, after compiling this for a
>         MIPS box, the gst-ffmpeg plugin now refuses to load and displays
>         the following at runtime:
>
>
>     Hm, bad testing, sorry.  This would be why gstreamer-libav 1.0
>     defaults to using it's own internal copy of libav then. :/
>
>     I see that gstreamer-ffmpeg_0.10 defaults to using the internal
>     libav, and as the API clearly changed we need to do that.  Can you
>     verify that removing external-libav from the PACKAGECONFIG fixes
>     this problem?
>
>     Ross
>
>


-- 
Mike Looijmans

Re: gst-ffmpeg is broken since the libav-9 introduction

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On 9 March 2015 at 18:18, Mike Looijmans <mike.looijmans@topic.nl> wrote:

> It works, and we're stuck with vendors providing no support for 1.x, and
> we've been trying to get the 1.x version integrated but that's a rather big
> task and the total lack of decent "how to migrate from 0.1 to 1.x" guides
> isn't doing much to speed that up either.
>

That's just depressing.  0.10 has been unmaintained for *ages* and I'd have
hoped that BSP providers would have upped their game somewhat.

Ross

[-- Attachment #2: Type: text/html, Size: 921 bytes --]

Re: gst-ffmpeg is broken since the libav-9 introduction

[Mike Looijmans]

On 09-03-15 16:24, Burton, Ross wrote:
>
> On 6 March 2015 at 17:51, Mike Looijmans <mike.looijmans@topic.nl
> <mailto:mike.looijmans@topic.nl>> wrote:
>
>     Commit 4ceff7d0a1f28eb1ce5d288111015b__ff8d5e9a7e "libav: drop older
>     0.8.* and use libav-9 by default" removed libav 0.8 in favor of the
>     "9" edition. However, after compiling this for a MIPS box, the
>     gst-ffmpeg plugin now refuses to load and displays the following at
>     runtime:
>
>
> Hm, bad testing, sorry.  This would be why gstreamer-libav 1.0 defaults
> to using it's own internal copy of libav then. :/

There's actually a page long rant that displays on screen if you link 
externally, like we do...

> I see that gstreamer-ffmpeg_0.10 defaults to using the internal libav,
> and as the API clearly changed we need to do that.  Can you verify that
> removing external-libav from the PACKAGECONFIG fixes this problem?

Tried that, it required a small patch to the configure.ac script to make 
it past the configure stage:

Index: gst-ffmpeg-0.10.13/configure.ac
===================================================================
--- gst-ffmpeg-0.10.13.orig/configure.ac
+++ gst-ffmpeg-0.10.13/configure.ac
@@ -385,7 +385,7 @@ else
       if test -z "$srcdir" -o "$srcdir" = .; then
         confcmd=./configure
       else
-       confcmd="$origdir"/"$ac_top_srcdir"/gst-libs/ext/libav/configure
+       confcmd="$ac_top_srcdir"/gst-libs/ext/libav/configure
       fi

       AS_MKDIR_P(["$ac_top_build_prefix"gst-libs/ext/libav])


Then it at least gets a bit further, but then you get bombed by a load 
of missing includes/headers/classes/andwhatnots during compile.

I guess some of the 50 or so patches are intented to make it work with 
the external library, and hence break building against the included one.

-- 
Mike Looijmans