[vitunes] Re: d.walter@xxxxxxx post needs approval
- From: Ryan Flannery <ryan.flannery@xxxxxxxxx>
- To: vitunes@xxxxxxxxxxxxx
- Date: Thu, 24 Feb 2011 01:56:25 -0500
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
Other related posts:
