[vlc-devel] Re: Proposal for a common D-Bus interface for media players
Sham Chukoury
eleusis at xmms.org
Wed Dec 6 04:01:24 CET 2006
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'.
Cheers.
-S
[1]
http://wiki.xmms2.xmms.se/index.php/IRC_Meeting/2006-11-27/Minutes#Amarok_and_XMMS2_Collaboration
[2] http://dan.chokola.com/files/xmms2-meeting/2006-11-27/transcript.txt
[3] http://xmms2.xmms.se/epydoc/public/xmmsclient.XMMS-class.html
[4] http://mpd.wikia.com/wiki/MusicPlayerDaemonCommands
[5] http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/service.py
[6] http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/xmms2.py
[7] http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/mpd.py
[8] http://xmms2.xmms.se/~eleusis/misc/client-api-table.html
--
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
mailing list