[OE-core] RFC: gstreamer 1.0 recipes

[Otavio Salvador]

On Sun, Apr 7, 2013 at 8:38 PM, Carlos Rafael Giani
<dv at pseudoterminal.org> wrote:
> 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?

Neat!!! :-D

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br