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 <mich...@obberon.com>
signature.asc
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list Exherbo-dev@lists.exherbo.org http://lists.exherbo.org/mailman/listinfo/exherbo-dev
