Re: [xine-devel] Proposal for a common D-Bus interface for media players

Hi all

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
> want.  
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 [1], 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 [2], 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 [3]
(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 [4] and Democracy TV [5] 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.

Olivier

[1] http://liris.cnrs.fr/advene/
[2] http://wiki.videolan.org/index.php/MediaControlAPI
[3] http://svn.gna.org/viewcvs/advene/trunk/lib/advene/player/
[4] http://www.transana.org/ 
[5] http://participatoryculture.org/

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html