<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello all,<br>
    <br>
    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
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="https://github.com/dv1/meta-gstreamer1.0">https://github.com/dv1/meta-gstreamer1.0</a>
    .<br>
    <br>
    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.<br>
    <br>
    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-" .<br>
    <br>
    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:<br>
    * gstreamer:
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    check_fix.patch (I could not reproduce the documented problem), and
    gstregistrybin.c/.h (why are these present?)<br>
    * 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)<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Thoughts?<br>
    <br>
    cheers,<br>
    Carlos<br>
  </body>
</html>