[vlc-devel] Re: Proposal for a common D-Bus interface for media players
eleusis at xmms.org
Wed Dec 6 04:01:24 CET 2006
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: 
(full transcript at )
>> I've been working recently of a D-Bus  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
I've done a bit of work on this, though in the form of a Python library (Chalyx
- for XMMS2  and MPD  clients), not an open spec or interface of any kind.
You can see the class defining the methods to be used at 
It's a bit of a compromise between the interfaces provided by XMMS2  and MPD
 (though biased a bit towards XMMS2). You can see a table comparing the
interfaces at  (Some MPRIS/BMP/BMPx calls are included, but they've never
been implemented in Chalyx)
>> I've copied this specification on the videolan wiki , 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'.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel