RFC: gstreamer 1.0 recipes

RFC: gstreamer 1.0 recipes

[Carlos Rafael Giani]

[-- 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 --]

Re: RFC: gstreamer 1.0 recipes

[Koen Kooi]

Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani <dv@pseudoterminal.org> het volgende geschreven:

> 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.

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

Re: RFC: gstreamer 1.0 recipes

[Burton, Ross]

Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani
<dv@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@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.

Ross

Re: RFC: gstreamer 1.0 recipes

[Carlos Rafael Giani]

On 2013-04-08 09:57, Koen Kooi wrote:
> Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani <dv@pseudoterminal.org> het volgende geschreven:
>
>>
>> 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

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

Re: RFC: gstreamer 1.0 recipes

[Koen Kooi]

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

> Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani
> <dv@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@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

Re: RFC: gstreamer 1.0 recipes

[Paul Eggleton]

On Monday 08 April 2013 12:47:51 Koen Kooi wrote:
> Op 8 apr. 2013, om 11:35 heeft "Burton, Ross" <ross.burton@intel.com> het 
volgende geschreven:
> > On 8 April 2013 08:57, Koen Kooi <koen@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?

Let's be clear, we're talking about bbappends in meta-oe and other software 
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.

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: RFC: gstreamer 1.0 recipes

[Carlos Rafael Giani]

On 2013-04-08 13:09, Paul Eggleton wrote:
>
> 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

Re: RFC: gstreamer 1.0 recipes

[Otavio Salvador]

On Sun, Apr 7, 2013 at 8:38 PM, Carlos Rafael Giani
<dv@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@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: RFC: gstreamer 1.0 recipes

[Carlos Rafael Giani]

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

Re: RFC: gstreamer 1.0 recipes

[Burton, Ross]

On 9 April 2013 00:00, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
> 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

Re: RFC: gstreamer 1.0 recipes

[Carlos Rafael Giani]

On 2013-04-09 11:32, Burton, Ross wrote:
> On 9 April 2013 00:00, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
>> 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

Okay, sounds good. But just liborc? Or yasm as well? yasm is crucial for 
ffmpeg and libav.

Carlos

Re: RFC: gstreamer 1.0 recipes

[Burton, Ross]

On 9 April 2013 10:50, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
> 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

Re: RFC: gstreamer 1.0 recipes

[Carlos Rafael Giani]

>
> 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

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