[OE-core] RFC: gstreamer 1.0 recipes

[Koen Kooi]

Op 8 apr. 2013, om 11:35 heeft "Burton, Ross" <ross.burton at intel.com> het volgende geschreven:

> Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani
> <dv at pseudoterminal.org> het volgende geschreven:
>> 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.
> 
> Excellent!  I'd love to see this merged into oe-core as soon as we've
> branched for 1.4.
> 
>> 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-" .
> 
> Perfect.
> 
>>> * gstreamer: check_fix.patch (I could not reproduce the documented problem), and gstregistrybin.c/.h (why are these present?)
> 
> The binary registry stuff is upstream now I think.
> 
>>> * 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)
> 
> Fine, is there are problems we'll soon find them again. :)
> 
>>> 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.
> 
> Build-time autodetection has to also be deterministic, i.e. it
> examines the MACHINE and layers instead of poking at the sysroot.
> 
> So...
> 
> On 8 April 2013 08:57, Koen Kooi <koen at dominion.thruhere.net> wrote:
>> 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).
> 
> (1) definitely needs to happen in my opinion  I'm not a massive fan of
> (2) in general as it leads to stuff changing simply by adding a layer
> - you may pull in meta-oe for some other packages but suddenly the
> GStreamer package is pulling in more dependencies.  I guess for things
> like GStreamer where the dependencies are generally isolated into
> separate packages this is less of an issue though.

Same thing is true to Qt, the *sql plugins are all subpackages. I realize 2) is unclear on wether the extra PACKAGECONFIG default to on or off. 

Both Qt and gstreamer have nice automated packaging of their plugins, so bbappends are generally safe to use, but both of them also have configure options that enable/disable complete libraries (e.g. QtOpenGL) that might trigger missing symbols in other libraries in Qt/gstreamer (again, QtOpenGL).

So were do we as OE(-core) community draw the line for bbappends in layers? For Qt it seems to be at "No bbappends allowed", but should we consider drawing it at "safe plugins only"? For generic layers like the ones in meta-oe I sure as hell don't want the "unsafe libraries" bbappends.

And for the sake of the argument, pretend that 'opengl' is not a DISTRO_FEATURE yet, we can fix the specific openGL case with a DISTRO_FEATURE PACKAGECONFIG.

regards,

Koen