[OE-core] RFC: gstreamer 1.0 recipes

[Koen Kooi]

Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani <dv at pseudoterminal.org> het volgende geschreven:

> Hello all,
> 
> to start working with GStreamer 1.0 on several embedded platforms, I decided to adapt the existing GStreamer recipes from danny for 1.0. Out of this I created a layer, which is hosted at https://github.com/dv1/meta-gstreamer1.0 .
> 
> I write this RFC, because I figure that GStreamer 1.0 support is already on TODO lists of several people, and will eventually end up in OE-Core, just like GStreamer 0.10 did. For this reason, I also didn't add it to the layer index.
> 
> I built the packages for several platforms (cubox, beagleboard, imx6), and they worked well. Since 1.0 has been designed to be able to coexist with 0.10 in the same rootfs, I changed the naming convention for the packages: they all start with "gstreamer1.0-" .
> 
> I also tried to reuse the existing patches. I was able to reuse three. Several others are no longer necessary. Four are unclear to me, so I did not port them:
> * gstreamer: check_fix.patch (I could not reproduce the documented problem), and gstregistrybin.c/.h (why are these present?)
> * gst-plugins-base: configure.ac-fix-subparse-plugin.patch (not sure what this is trying to fix, and this line does not exist in 1.0), and gst-plugins-base-tremor.patch (again, works well without it)
> 
> gst-ffmpeg was replaced by gst-libav upstream. So was gst-openmax (gst-omx is its successor). gst-omx has special support for the Raspberry Pi and its custom OpenMax IL implementation. The recipe is designed in a way that allows for setting the target to something like "rpi", and the recipe then sets the PACKAGE_ARCH automatically to MACHINE_ARCH. However, I wasn't able to test it on an RPi yet, since I do not have one. I will get access to one in a few days.
> 
> I am also considering some kind of autodetection for when yasm and liborc are available (for example, because meta-oe was added to bblayers.conf), and then switches on Orc and enables yasm in gst-libav. Or better yet, if libav is available as a recipe, it lets gst-libav use it instead of its internal copy. These autodetections would improve performance significantly.

I've been meaning to ask the same questions, since I need both orc and external libav to make gstreamer  (0.10, but still) useable on my platforms. I came up with the following ideas:

1) Make every external dep a PACKAGECONFIG option in OE-core gstreamer
2) Add bbappends with extra PACKAGECONFIG options for gstreamer in the layer that has the external dep
3) add bbappens in the DISTRO layer that enables extra external dependencies.

Angstrom is currently using 3) and I absolutely hate it. 2) is scales a lot better, but apparently is verboten judging from the patches sent that remove the qt bbappends that do the same.
Which leaves 1), which will cause problems for most users, since they will spot the PACKAGECONFIG options but not bother to read the comments saying they need to enable extra layers.

I favour 1) since that has all the knowledge in a single place, looked after by the OE gst maintainer (which we don't have yet, but still).

regards,

Koen