Hi, On Sat, Feb 19, 2011 at 5:24 PM, Peter Polacik <polacik.p@xxxxxxxxx> wrote: > Hi Ryan and list, > > On Sat, 2011-02-19 at 16:54 -0500, Ryan Flannery wrote: >> Hi Daniel, >> >> ... >> >> One thought is the following: >> 1. The player structure has a "backend" type, from, say, an enum of >> supported backends. >> 2. The functions in player.c switch on this and execute the >> appropriate functions for each backend. >> 3. The code for each backend could be in seperate files, say >> "player_mplayer.[h|c]", with just the functions needed for the vitunes >> functionality. Or a subdirectory "player/mplayer.[h|c]. I think I >> like the subdirectory idea better. >> >> With this, we could have one build support multiple backends, and >> perhaps a command-line flag or config option to select which. >> >> The big problem I see with supporting multiple backends: >> 1. The player_monitor() function... that's a nasty bit of >> mplayer-specific goo. It handles the timing update and playing the >> next file in a playlist when one ends. Is that easy to port to >> gstreamer? Further, is it easy to get a unified way of doing things >> between gstreamer/mplayer/foo? > > I got an idea, wouldn't it be easier, if we did it using "modules", > dynamically loadable objects, using let's say dlopen(3) etc.? > This is a possibility too... and once multiple-backend support is working (and perhaps we get more backends), I think this would be a good choice. -ryan