Choosing a Phonon backend

Tanguy Krotoff tkrotoff at gmail.com
Thu Mar 27 11:33:28 GMT 2008


On Wed, Mar 26, 2008 at 8:43 PM, Matthias Kretz <kretz at kde.org> wrote:
>  Yes, I'm considering adding something like a set of flags and then the
>  application can say
>
>  Phonon::setRequiredFeatures(Phonon::SomeFeature | Phonon::SomeOtherFeature);
>
>  The remaining problem is that there must be at least one backend for every
>  platform that supports all features otherwise the above call could result in
>  a situation where no backend would fit - which doesn't make sense.
>
>  And yeah, I don't think the application can be smarter than the framework in
>  deciding what backend to use. That's why there's no API to select the backend
>  from the API.

What about the user? can he be smarter than the framework to decide?
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)

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"

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

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.

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));

Just my 2c :p

-- 
Tanguy Krotoff <tkrotoff at gmail.com>
+33 6 68 42 70 24



More information about the kde-multimedia mailing list