[vlc-devel] Re: [xine-devel] Proposal for a common D-Bus interface for media players
olivier.aubert at liris.cnrs.fr
Thu Dec 7 22:45:50 CET 2006
I would like to share the point of view of a developer who needs to have
the possibility to control various *video* players.
On Mon, 2006-12-04 at 16:27 -0800, Brian J. Tarricone wrote:
> That's somewhat similar to my reaction. I can see a need for a
> desktop/player-neutral audio API for things like sound notifications on
> certain events, but I don't see why individual media players need to
> have the same interface. Users can already choose to use whatever they
Because a media player is not only a GUI, it is also a rendering engine,
with its specificities, that can be of interest for developers.
> Embedding audio/video widgets in applications might be an interesting
> use for this. However, this bit is way more complicated than just
> defining a common control interface, and varying feature-sets among
> different players makes it hard to have real drop-in replacements.
Not really hard for a core part, that is provided anyway by any player:
play, pause, go to a given position... Optional features (captioning,
screenshots, playlist handling, media library handling) may be optional.
> I'm not trying to say this is a stupid idea, I'm just saying I don't
> understand how it would be used by users and/or application developers.
> Come up with a decent list of *specific* potential real-world users of
> this interface, and then we have a purpose.
Well, here is a concrete example: my research project, Advene , is
about hypervideos (annotation AV documents and provide ways to visualise
them). In order to implement it, I needed to control a video player. I
chose VLC 4 years ago, because at the time it was the only free,
cross-platform player able to play DVDs. I have for this defined
MediaControl , a player-agnostic control API, expanding on a
specification from the OMG. I have implemented this API in VLC, and
have also using written a plugin to control gstreamer the same way 
(I do not talk about the xine and mplayer rc-based implementations, that
are really too slow).
Why would I need to have different video engines? Because of different
features: VLC is unable to do frame-precise positioning, which some
people need, but it is able to render SVG graphics, since I wrote the
code. So I just let the user choose the engine that fits his needs.
To sum it up:
- a unified API (at least for common features) for video players on
linux is a desirable and desired thing.
- there are many video-based projects that could make use of it (Advene
of course, but I know that Transana  and Democracy TV  developers
really need this too for instance).
- the access method (DBus, Corba, bindings...) is IMHO secondary: it
should first be a programming API, at least for performance reasons.
Once it is available, writing a DBus binding is trivial.
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