[Exherbo-dev] Dealing with media options
arkanoid at exherbo.org
Thu Aug 6 01:23:21 BST 2009
Excerpts from Michael Forney's message of Thu Aug 06 01:23:51 +0200 2009:
> Right now, Exherbo's media options are a big mess.
> For example, k3b uses the lame flag to mean "mp3 encoding with lame",
> and the mp3 flag to mean "mp3 decoding with mad". mplayer does the
> exact opposite and uses mp3 to mean "mp3 encoding with lame", and
> mad to mean "mp3 decoding with mad".
These are obvious candidates for consolidation and I see no problem in
> 1. Only use specification flags (get rid of lame, mad, x264, a52dec)
This is by far the most user-friendly approach, since an average user
cares about mp3-support, not whether we use lame or another library to
> However, some packages support decoding and encoding as
> separate options (e.g. mad and lame), and consolidating them would
> allow less control over your system.
This is actually not that big an issue since we really don't care about
providing every conceivable option and combination thereof.
> This would also prevent users from
> differentiating between encode and decode support with a certain flag.
The current flags rarely make it clear whether they concern encoding or
decoding and I deliberately dropped the encode/decode options from the
> Although only a minor detail, this solution would make the plugin
> options in gst-plugins-ugly confusing because the plugin names are
> implementation specific (x264, mad, lame, a52dec, etc).
This is the one issue I have with this idea and it doesn't hit
gst-plugins-ugly exclusively. The problem also arise whenever we have two
different libraries that provide the same functionality (e.g. h264 decode
support). I'm not sure whether this is currently the case with any of
the media-related exhereseseses but except for those who really care
(me) and might need to be able to switch between the different libraries
(me) this is hardly relevant. And letting the maintainer choose one
library over the other would be consistent with what we currently do for
things like openssl implementations. If anyone needs more finegrained
control, they can maintain exheres in their local repos.
In a nutshell I prefer this solution.
> 2. Only use implementation flags (get rid of mp3, a52, h264)
Messy, unmaintainable for users and with only a few benefits.
> This would help the user understand what exactly they are enabling, but
> would require them to look up what various libraries do and it wouldn't
> make their options.conf as clean. Personally, I think would be handy to
> be given this additional information.
The additional information is easy to provide through option
descriptions in annotations:
mp3 [[ description = [ Enable mp3 support through mad (decoding) and lame (encoding) ] ]]"
> I think the ideal solution is to use the specification as the option,
> but at the same time differentiate between encoding support, decoding
> support, and both.
Most media applications only deal with either encoding or decoding, not
both. In the few cases (such as mplayer) where there are options for
both encoding and decoding we can enable both. It will result in a few
additional dependencies being pulled in for those who only want mplayer
but it's hardly relevant on a modern system. If you have special needs
it is trivial to maintain your own exheres or even build by hand and use
> However, I have absolutely no idea how this could be implemented cleanly.
The gentoo mplayer ebuild shows you a great way not to do it ;)
More information about the Exherbo-dev