[Exherbo-dev] Dealing with media options

Michael Forney michael at obberon.com
Thu Aug 6 00:23:51 BST 2009


Right now, Exherbo's media options are a big mess. We often have flags
for both the specification (mp3, a52, h264) and the implementation
(lame, mad, a52dec, x264). Media packages use these options to mean
different things.

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

There our countless other packages that have this problem, and I think
that making these options consistent would help the user understand
exactly what functionality (s)he is enabling with a certain flag.

There are a couple solutions I can see to this problem, but it seems to
me that they both have several pros and cons associated with them.

----

1. Only use specification flags (get rid of lame, mad, x264, a52dec)

This solution would make it easier for most users because they would
only have to enable 'mp3', and would get all mp3 related functionality.
Also, I think the correct usage of options is to say "I will enable
this feature", rather than "I will enable this feature by using this
library". 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 would also prevent users from
differentiating between encode and decode support with a certain flag.
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).

From my discussion with kloeri and Ingmar on IRC, it seems that this is
the favorite option.

2. Only use implementation flags (get rid of mp3, a52, h264)

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.

----

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. However, I have absolutely no idea how this could be
implemented cleanly.

Any feedback or ideas about this issue would be appreciated :)

-- 
Michael Forney <michael at obberon.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20090805/2fc8f81e/attachment.pgp>


More information about the Exherbo-dev mailing list