Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Carlos Rafael Giani <dv@pseudoterminal.org>
To: Koen Kooi <koen@dominion.thruhere.net>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: RFC: gstreamer 1.0 recipes
Date: Mon, 08 Apr 2013 11:36:18 +0200	[thread overview]
Message-ID: <51628F92.2070600@pseudoterminal.org> (raw)
In-Reply-To: <9E7EB4C7-5A2C-4754-B37E-A0F048F22BBF@dominion.thruhere.net>

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



  parent reply	other threads:[~2013-04-08  9:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-07 23:38 RFC: gstreamer 1.0 recipes Carlos Rafael Giani
2013-04-08  7:57 ` Koen Kooi
2013-04-08  9:35   ` Burton, Ross
2013-04-08 10:47     ` Koen Kooi
2013-04-08 11:09       ` Paul Eggleton
2013-04-08 11:14         ` Carlos Rafael Giani
2013-04-08  9:36   ` Carlos Rafael Giani [this message]
2013-04-15  1:21   ` Carlos Rafael Giani
2013-04-08 13:39 ` Otavio Salvador
2013-04-08 23:00 ` Carlos Rafael Giani
2013-04-09  9:32   ` Burton, Ross
2013-04-09  9:50     ` Carlos Rafael Giani
2013-04-09 10:02       ` Burton, Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51628F92.2070600@pseudoterminal.org \
    --to=dv@pseudoterminal.org \
    --cc=koen@dominion.thruhere.net \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox