Skip to content

Media Player Interfaces

Erik Massop edited this page Nov 4, 2017 · 1 revision


This page is an attempt at bringing together information about various works in progress to produce a common media player control interface. Note that in the context of this page, interface refers to interface in the sense of an API, not an interface through which a user interacts with a program.

Note about the mailing list mpris at videolan dot org: It should be an as LOW traffic list as possible and used only to coordinate the work, and when developers disagree on a part of the spec. Otherwise, please use this wiki page.



In August 2005, Milosz Derezynski (deadchip) and Frederic Fondriest (ciberfred) were working on defining an interface for remotely controlling BMPx (as opposed to using the BMPx GUI) over DBUS:

 hey deadchip , one things i'm currently thinking, we could do something with dbus to uniformize call functions, so each player could share same 'dbus-commands' <~deadchip> ah <~deadchip> yeah <~deadchip> that would be a very good idea  it could be better to let user choose the daemon they wants :)  like xmms2, bmpx, or lamip or well mpd or others <~deadchip> yeah <~deadchip> that is really good  so binaries commands audio could send informations from user to theses daemons without need to re-code somethings different but similare for another audio player

Thus MPRIS (Media Player Remote Interface Specification) was born - a fairly generic interface with commands that could be applied to control a wide range of media players. However, even though the phrase 'Media Player' is present in MPRIS, the specification was developed with the assumption that it would be applied to audio players.


  • Defines commands for controlling a media player (play, pause, stop, etc).
  • Defines signals that notify clients of certain events on the media player.
  • Does NOT define audio or video data streaming protocols.
    • That is, a client can't request audio or video stream data over MPRIS


Meanwhile, Sham Chukoury (eleusis) was working on an XMMS2 client named HaX (now known as Chalyx). At some point, he decided it would be a great idea to be able to have a single client that could control multiple players, such as XMMS2, MPD and maybe even BMPx. So he made an API comparison table.

Most of the actions defined in the table were eventually defined in the Service abstract class in Chalyx (and subsequently XMMS2 and MPD service modules were developed). As such, any client that uses the Chalyx library (such as Kjell and Insanity) is able to control both XMMS2 and MPD. The design of Chalyx permits the development of additional 'service' modules to allow clients to control other music player backends.


Fast forward to November 2006 and Rafaël Carré from the VLC project decided to implement a DBUS control interface for VLC. He discovered MPRIS and decided to adapt it to his needs. Rafaël also decided to mail other media player projects to revive the spirit of MPRIS, and all hell broke loose across 10 different mailing lists. Then, Mirsal Ennaime tried to bring the project back from the grave, with Rafaël Carré and BMPx developers.



Discussion was proceeding on the vlc-devel mailing list. (see specific thread linked below) Milosz has proposed to set up an mpris-devel mailing list hosted by BMPx. A dedicated mpris at mailing list is set up, it should be an as LOW traffic list as possible and used only to coordinate the work and when developpers disagree on a part of the spec. Otherwise, please use this wiki page.



  • Widespread


  • Doesn't work well over TCP? (e.g. compare with MPD's & XMMS2's support for tcp sockets)

Projects involved


For XMMS2, a proxy could be developed to translate between DBUS and XMMS2's own IPC mechanism. (Anders may have already done some work on this)





Dragon player


API Comparison

The spec


See Also

Clone this wiki locally
You can’t perform that action at this time.