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

[varokan]

Brian J. Tarricone wrote:
> Mike Melanson wrote:
> >> Allow me to inaugurate the flame war...
> >>
> >> Rafaël Carré wrote:
> >>> 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 read this as: "Real problems are too hard to solve. Let's create
> >> different problems and solve those instead!"
> >>
> >> :)
>
> 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.  If I'm just an application that wants to launch the user's
> preferred audio player (for example), there are already established ways
> of doing that that don't even require D-Bus.
>
> 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.
Folks, I completely disagree. My pet project can use either xine or
MPLayer as a MediaBackend (VLC stalled due to ever changing API). The
reason for me was simply to give the user flexibility and a choice
instead of making the choice for them.

Say you have xine but QDVDAuthor would only work with VLC or gstreamer.
Why force the install of all the other 'junk' onto the user if not
necessary ?

Kaffeine I believe can also use either media player.

Looking at phonon this seems to be exactly where things are heading for
the KDE desktop, a unified multi media API, that works with xine and NMM.

Also not to forget one player might have advantages over the other for
the end user.
E.g xine is linked against my code, thus I can only use 64 bit
compatible codecs. MPlayer is 'remotely conrolled' and I use the 32 bit
version, this way my 64 bit compiled program can take advantage of 32
bit codecs.

>
> Really, the only common use-case I can see here is the one mentioned in
> the original post: writing a little remote control GUI for Kicker, or
> gnome-panel, or xfce4-panel or whatever, and being able to have it
> control any media player that supports The Interface.  For such a
> limited use case, what's the point?
Especially Multimedia applications are getting fatter and fatter and
while we could argue about the use of those fat apps, the matter of fact
is it takes a long time to write one.
If there would be a unified interface it would allow those apps to be
future proof.
>
> 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.
QDVDAuthor, any simple media player (play, stop, pause, seek,
screenshot) instead of trying to find the best API/Player and wast a lot
of time doing so, people could just take advantage of a unified interface.
>
>     -brian
>
> P.S.  Maybe this should be moved to something like xdg at freedesktop.org?
>  I know I'm only subscribed to one of the lists on this cross-post, and
> I have no idea if any of the other three will even go through.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> xine-devel mailing list
> xine-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xine-devel
>