Talk:Media Player Interfaces

This is a difficult project by its nature as it's bridging projects with different philosophies and goals. It should be pretty obvious that there's going to be friction in creating some sort of DBus implementation. To alleviate the potential clashes between projects I originally suggested some sort of capabilities negotiation might be in order. However I, and others on the mailing lists, have come up with a set of ideas that I think we need to decide on first before proceeding to actually implement.

KISS

• just do basic playback functions (play, pause, stop, prev, next)
• limited functionality, but easy on clients and developers

Limit the spec to similar media players

• medialib players Amarok, XMMS2, and BMPx
• playlist players Amarok, XMMS2, BMPx, and VLC
• destroys potential for other players to implement the spec

Capabilities negotiation

• should only have a handful of sets of functionalities:
  • playback
  • playlist
  • mediainfo
  • medialib
• adds complication to the spec and clients have to deal with capabilities

Common intersection object and individual objects

• make a common media player object where all the media player APIs overlap
• add objects that expose individual media player APIs
• begs the question of why one should bother with DBus instead of native API

Daniel Chokola

---

First, we need to ask the question: "What is the purpose of this interface?"

From my point of view it should be an interface used by application that primarily isn't controlling the media player. Some examples:

• voip application that wants to automatically stop playback when there is an incomming call
• irc client script that announces current track
• "enqueue in mediaplayer" in contextmenu in filebrowser
• some alarm clock app that starts music playback with a specific track 5 minutes before the real alarm goes on.
• dock/panel-app for showing current song.
• script that automatically stops music when your bluetooth phone goes out of range.
• whatever, if the functionality is provided unexpected uses tend to pop up.

With a common interface this kind of apps doesn't have to know about different media players, they just fire off some dbus messages to a standard place.

To serve its purpose it must be very easy for the application to interface with the mediaplayer. Therefore the interface has to be as simple as possible, containing only the basic stuff, no capabilities negotiation should be needed.

Anders Gustafsson

---

Well, I think that a guaranteed basic set of capabilities should be something like:

• play, pause, stop, next, prev
• get a playlist entry's title/length, convenience RPCs for the current entry
• set playback volume, mute, adjust balance

Some players, e.g. Audacious, have some library-like qualities, such as Tuples, it may be better to split up medialib into something like:

• library/collections
• full-metadata

Also, DBus and my sanity do not get along, and I am sure it is the same way for others. A common library should be a must. I'd suggest MIT licencing for that.

--William Pitcock 10:20, 7 December 2006 (CET)

---

The spec looks like a good start to me, although I've got a couple of nitpicks/questions:

• The XMMS2 version has seeking in miliseconds, but the "length" metadata is only in seconds - I think that it would be worth making "length" be miliseconds too. The BMPx/VLC version has it as an int between 0 and 100, and if we wanted "fraction" rather than "position" seeking, using a float so you have arbitrary position would be a good idea. After all, an average song would have granularity of two or three seconds with 0-100, let along songthing longer like a video.

• Similarly for audio volume, using a 0.0-1.0 float is probably better than a 0-100 integer. Not that you really need the accuracy, but I don't see any reason to artificially limit the granularity.

• Much of the Tracklist-related API either doesn't make sense or doesn't have the same meaning for "library based" players that don't have a "main tracklist". Some library based players have a "queue" which kind of maps to the idea of "main playlist" but not all have them. However some of the API, particularly previous/next and shuffle/repeat, still does make sense for them. One other option would be for these players to expose multiple tracklist objects, but that would mean moving some of the API out somewhere else.

• Also, there should probably be some signal that the tracklist has changed, so client will know that their information is out of date.

• On the metadata, video-codec and audio-codec are listed as being listed "as fourcc". A reasonable number of players (particularly audio-only ones) won't know this without embedding a mimetype->fourcc mapping table, perhaps using mimetype would be better?

James Livingston

D-Bus nits

Some of the D-Bus details that I'm worried about:

• 1. If I take D-Bus interfaces to be exactly like Java interfaces, then the current spec is weird in that it seems to suggest implementing one interface (org.freedesktop.MediaPlayer) across multiple objects (exported as /, /Player, /TrackList)... unless it *is* meant to be implemented in one object (which I don't think is the original intention).
  • This makes it very difficult to implement in something like Qt, where interfaces are autogenerated. Basically, the tool tries to generate three different objects with the name OrgFreedesktopMusicPlayer, and fails when you try to use all of them from the same code. --Randomguy3 10:56, 27 January 2008 (CET)
• 2. org.freedesktop.MediaPlayer currently has 2 methods with the name GetMetadata. This is problematic for languages which don't have method overloading (e.g. Python). But see also point 1; if the methods are on different interfaces then there would be no problem, as far as I know.
• 3. From my limited D-Bus knowledge, the normal way for multiple applications to advertise a service ("I'm a music player!") is by trying to grab a well-known bus name; D-Bus has a queue to handle the case when multiple applications try to do that on one bus name. I don't really understand the reason for the mechanism used in the spec, of having org.mpris.my_music_player instead of letting apps try to grab some well-known bus name (e.g. org.freedesktop.MusicPlayer or org.mpris.Something), perhaps in addition to com.my_music_player.Foo.
• 4. The /TrackList er.. stuff.. isn't very D-Bus-y, according to 1. I talked to Milosz and agreed that having each track as a D-Bus object is not a good idea either, but I forgot that D-Bus has fallback objects, which is how--for example--GConf exports all of its config items through D-Bus. Combined with the issues that James Livingston mentioned, the TrackList API seems a lot of trouble for little gain. I don't see my average blog poster app, IM status plugin, or in-panel music player controller needing to know about and manipulate playlists--the user will want to bring up the real player in most cases. I'd suggest at least leaving it out of the basic spec.

(By the way, the link in point 4 is really worth reading.)

Sorry for the un-wiki-ish way of my writing; I haven't really used wikis for quite some time.

--Johannes Sasongko, 08:32, 13 August 2007 (CEST)