RFC: gstreamer 1.0 recipes

[Carlos Rafael Giani <dv@pseudoterminal.org>]

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

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.

Thoughts?

cheers,
Carlos

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