Choosing a Phonon backend

[Matthias Kretz]

On Thursday 27 March 2008, Tanguy Krotoff wrote:
> What about the user? can he be smarter than the framework to decide?

Depends. Currently with Phonon + KDE the backend decision is up to the user. 
He will base is decision on experience and hear-say. :-)

> I'm developing a VLC + MPlayer backend.
> So I imagine a video app that let's the user choose which backend he wants.
>
> MPlayer does not handle DVD menus, VLC does. From the video app it
> would be nice to say "for DVD playback I prefer the VLC backend and
> for others videos I prefer MPlayer" or "for .mov files I prefer
> MPlayer, for the rest VLC".
> There will never be a backend "to rule them all" (ok, yes, Phonon will
> huhu)

What should happen if an application handles two media sources at the same 
time which would prompt Phonon to use two different backends?

No, I think the only sensible path is to stick with one backend per app. And 
if the backend has problems fix them there. We'll need some backend to do 
everything (and do it right) and until we know which project will deliver 
we'll have a small mess - while still placing our bets somewhere and helping 
out... (like TT did with GStreamer).

> Also from a developer point of vue, when I'm testing the VLC backend,
> I have to remove all others backends (*.so/*.dll) from Qt directory
> phonon_backend.
>
> I don't know how to solve nicely/elegantly this problem. What I know
> is that I don't want to see in a video app FAQ:
> "to use the MPlayer backend, go to blabla phonon_backend, delete all
> others backends *.so/*.dll/*.dylib"

Right, phonon without KDE is not really prepared for more than one backend. 
It'll use the first one it finds in the QT_PLUGIN_PATH.

> A specific backend can be best for music playback, another for DVD
> playback ect...
> I guess for music editing it would be another ect...

If we'll end with such a situation then I'll call it a failure. That would be 
a mess. No the goal must be one fully functional backend per platform.

> I think there is 2 levels:
> - global level (KDE level): the default backend
> - local level (app level): the best backend for a specific app
>
> And it's already the case. Lots of video app uses their own backend by
> using directly MPlayer process, libxine or libvlc... Phonon can clean
> up this mess and avoid to duplicate efforts.

But then what would be the gain of Phonon?

> And yet, Phonon API and implementation from my point of vue, should
> stay simple and clean.
>
>
> A bit of a different subject. How can I simply extend Phonon API?
> Let's say libvlc provides a libvlc_get_fps() and I want to provide
> this to the video app. What is the elegant way to do this? For the
> moment I do this:
>
> //Hacking into the backend...
> QObject * backend = Phonon::Factory::backend();
> const QMetaObject * backendHacking = backend->metaObject();
> QString backendInfos;
> backendHacking->invokeMethod(backend, "MY_FUNCTION",
> Q_RETURN_ARG(QString, backendInfos));

Thanks for this code example. factory.h was never meant to get installed. This 
should get fixed really soon in Qt.

Anyway, you can't use the Factory namespace. It's internal and may change in 
future versions of Phonon. The only thing you can do for backend specific 
hacks is to push data from the backend into a QObject property of the 
frontend object. It's ugly and it should not be used in production code if 
possible.

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20080328/36e830e4/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia