On 11 January 2016 at 16:41, Tim <ignored_mailbox@xxxxxxxxxxxx> wrote: > Allegedly, on or about 11 January 2016, Fernando Cassia sent: >> Call me old fashioned, but I prefer a static, single binary to perform >> a simple task like playing a mp3 file - you know, the Unix way, do one >> thing and do it self-cointained. > > There's some logic to that, but all some illogic. Would you have yet > another binary program to play wav files, another for oggs, another for > flac, and have to call the right one for each audio file you want to > play? Or would you use the one player for any type of audio file, and > let it make use of the appropriate codec for the file? > > The idea of having a common codec for handling, say mp3 files, has merit > in itself, along the lines you're promoting for the binary player. If > half a dozen programs all use the same codec file, that's more people > debugging and improving a codec. > > Personally, I think that there's far too many different types of media > file to have a single binary player that handles them all. There would > be poorly supported ones that coders didn't really place much priority > on. And I certainly wouldn't want to have to use a plethora of > different binary players for each different audio filetype. This is sort of what plugin architectures try to do too (like gstreamer). The trick is having an interface that can handle the required data while the application is able to look for the presence of the component it needs for a particular data type. That can be done with plugins or binaries (see applications like grip which use separate tools to do encoding). It does take more work, because you need a framework that can handle that discovery (rather than just statically link in every needed library, even handing off to the different demuxing and decoding algorithms is harder than a tool that works with a single format), and to fill in any gaps in the formats that are supported through that interface. The result is applications that use those frameworks end up more complex and have to wait for the framework to move before they can support new things, while lightweight tools can move more quickly, but end up becoming non-lightweight tools in the process. I think this is why new 'minimalist' players appear every so often. And of course every shiny new video codec starts off supported in one particular implementation and needs to be taken up by the others (even before you bring in patent issues). -- imalone http://ibmalone.blogspot.co.uk -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
