On 09-03-15 16:24, Burton, Ross wrote:
On 6 March 2015 at 17:51, Mike Looijmans <mike.looijm...@topic.nl
<mailto:mike.looijm...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core