Re: [Rhythmbox-devel] Proposal for a common D-Bus interface for media players

Hello world.

Seb Ruiz wrote:
Actually, whilst I was in san francisco, I spoke with the xmms2 folks
about the same thing. we totally agreed on the necessity for it.

Indeed, this was discussed a bit during a meeting: [1]
(full transcript at [2])

I've been working recently of a D-Bus [2] control interface for VLC, to permit other applications to interact with VLC.
This implements basic functions such as:
        - playback control (Play/Pause/Next..)
        - information on medias (Meta-data/Length)
        - playlist editing (Add new elements to play)

I've been looking at how other media players already implemented that, and I thought all their interfaces were highly redundant, and could benefit of implementing a single, common, shared interface.

That would let developers use this interface in their programs, and let their users decide of which media player they wanna use. All about FREEDOM.

I've done a bit of work on this, though in the form of a Python library (Chalyx - for XMMS2 [3] and MPD [4] clients), not an open spec or interface of any kind. You can see the class defining the methods to be used at [5] It's a bit of a compromise between the interfaces provided by XMMS2 [6] and MPD [7] (though biased a bit towards XMMS2). You can see a table comparing the interfaces at [8] (Some MPRIS/BMP/BMPx calls are included, but they've never been implemented in Chalyx)

I've copied this specification on the videolan wiki [6], and modified it to my needs. I tried to keep it as general as possible. However this still needs more work, and comments.

This is why i'm reaching you, developers of some media players, to comment what i've done or work with me, until that specification fulfills your needs, and can be used in a real world.

This specification should stay as generic as possible, because media players that want to make specific methods available with D-Bus can do it through their specific interface.

For example, basic methods would be available on the service org.freedesktop.MediaPlayer and VLC would make streaming methods available on the service org.videolan.vlc. So, a basic control applet for the KDE panel originally written for amarok would be able to control VLC, and a complex pygtk script would control streaming features of VLC.

Re: 'The Service' on the DBus-spec page, am I to understand that only one player supporting the spec may be running at any one time? That makes sense from the point of view that the user might want a single 'default' player to control, but what if the user wants 2 such players running at a time? For example, listening to music using VLC while debugging XMMS2? ;)

Re: generic interface, does that mean there could be standard interface extensions? For example, players with access to a media library could have an extended interface 'org.freedesktop.MediaPlayer.Library'.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]