RFC: gstreamer 1.0 recipes
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
Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani <[email protected]> het volgende geschreven:
Quoted 8 lines
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-" .
Quoted 7 lines
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_ARCHautomatically toMACHINE_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
Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani <[email protected]> het volgende geschreven:
Quoted 6 lines
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.
Quoted 3 lines
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.
Quoted 1 line
Quoted 1 line
* 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.
Quoted 1 line
Quoted 1 line
* 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. :)
Quoted 1 line
Quoted 1 line
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...
Quoted 10 lines · Koen Kooi
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.
Ross
Op 8 apr. 2013, om 11:35 heeft "Burton, Ross" <[email protected]> het volgende geschreven:
Quoted 43 lines
Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani <[email protected]> het volgende geschreven:
Quoted 6 lines
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.
Quoted 3 lines
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.
Quoted 1 line
Quoted 1 line
* 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.
Quoted 1 line
Quoted 1 line
* 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. :)
Quoted 1 line
Quoted 1 line
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...
Quoted 9 lines · Koen Kooi
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.
Quoted 8 lines
Quoted 1 line
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
Quoted 1 line · On Monday 08 April 2013 12:47:51 Koen Kooi wrote:
Op 8 apr. 2013, om 11:35 heeft "Burton, Ross" <[email protected]> het
volgende geschreven:
Quoted 29 lines
Quoted 17 lines · Koen Kooi
Quoted 16 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 7 lines
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?
Let's be clear, we're talking about bbappends in meta-oe and other software layers.
Quoted 3 lines
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.
Apart from not having its configuration changed, given how huge Qt is I want it to *not* be rebuilt just as a consequence of adding meta-oe to my bblayers.conf. (Of course I can't have that yet because the bbappends have to at least have PRINC set in them still, but as soon as PV gets bumped...).
Honestly I think solution 1 is fine; in fact we already have that for some recipes. We would have had PACKAGECONFIG for these Qt SQL plugins except that as I've mentioned numbers of times, PACKAGECONFIG can't work for these three- state options. One alternative would be to auto-add DEPENDS / CFLAGS based on QT_SQL_DRIVER_FLAGS.
Returning to the original topic, a case could be made for just bringing orc and libav into OE-Core. That's not going to work for every situation but we ought to be looking at these kind of things on a case-by-case basis.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 8 lines · Paul Eggleton
Returning to the original topic, a case could be made for just bringing orc and libav into OE-Core. That's not going to work for every situation but we ought to be looking at these kind of things on a case-by-case basis.
Cheers,
Paul
You should add yasm to that list. libav isn't happy without it ;)
Carlos
Quoted 10 lines · Koen Kooi
Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani <[email protected]> het volgende geschreven:
Quoted 2 lines
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.
Quoted 8 lines
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
So, the problems of these option are:
1) People might not make proper use of it
2) Seems to be disallowed
3) Is indeed quite inconvenient, since many people require different plugins, and there is always the chance that the ones enabled in the distro are not enough or not configured in the desired way
Option 1) sounds like the way to go for me too. Is it allowed to stick a file like "readme-extra-plugins.txt" in the recipes-multimedia/gstreamer/ directory? Because then, questions about performance,orc,yasm can be answered by pointing to that file. At least there would be a documentation.. In addition, regarding orc and yasm, it would help to print out a warning about the performance, briefly describing the situation (yasm and orc missing), and a link to the documentation with details.
carlos
Quoted 7 lines
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.
Quoted 8 lines
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
I have implemented option 1) now. It could be better in the -bad recipe, which contains a lot of --disable-XYZ switches. I am thinking of a patch to make external dependencies opt-in instead of opt-out. But, all the external dependencies with known existing recipes have a packageconfig now. This includes orc and yasm.
cheers,
Carlos
Quoted 34 lines · Carlos Rafael Giani
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_ARCHautomatically toMACHINE_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.
Quoted 7 lines
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: [email protected] http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Hello,
thinking about this whole issue I began to wonder: why is gstreamer in oe-core and not in meta-multimedia? wouldnt it be easier then to move liborc into meta-multimedia as well?
Or is gstreamer considered an essential component for many installations, thus justifying its presence in oe-core?
regards,
carlos
Quoted 5 lines · Carlos Rafael Giani
thinking about this whole issue I began to wonder: why is gstreamer in oe-core and not in meta-multimedia?
wouldnt it be easier then to move liborc into meta-multimedia as well? Or is gstreamer considered an essential component for many installations, thus justifying its presence in oe-core?
Yes, it's common enough, and I'd support moving liborc to oe-core in 1.5.
There's always a grey area for oe-core verses meta-something, but there's no point in oe-core just consisting of gcc and libc.
Ross
Quoted 6 lines · Ross
Quoted 5 lines · Carlos Rafael Giani
thinking about this whole issue I began to wonder: why is gstreamer in oe-core and not in meta-multimedia?
wouldnt it be easier then to move liborc into meta-multimedia as well? Or is gstreamer considered an essential component for many installations, thus justifying its presence in oe-core?
Quoted 6 lines
Yes, it's common enough, and I'd support moving liborc to oe-core in 1.5.
There's always a grey area for oe-core verses meta-something, but there's no point in oe-core just consisting of gcc and libc.
Ross
Okay, sounds good. But just liborc? Or yasm as well? yasm is crucial for ffmpeg and libav.
Carlos
Quoted 2 lines · Carlos Rafael Giani
Okay, sounds good. But just liborc? Or yasm as well? yasm is crucial for ffmpeg and libav.
Good question and I can't give an instant answer for that.
Ross