Choosing a Phonon backend

[Fabio Locati]

On Saturday 29 March 2008 09:09:36 Tanguy Krotoff wrote:
> Nice thread :p
>
> My app is specific and needs specials features that the default
> backend is not designed for.
> Say my app does not simply use Phonon::playSound()
>
> What I want to do is:
>
> * Choose MY app Phonon backend
>
> Because otherwise my very specific app is almost USELESS for my users.
> For example DS9 backend under Windows is useless for a video player
> because it does not integrate codecs as VLC or MPlayer does. I guess
> it is the same under MacOSX.
> In the future it will be for another good reason (BlueRay...), who knows?
> For an app that does only use Phonon::playSound() yes it is definitely
> enough.
>
> What is the cost of providing
> bool Phonon::setBackendName()
> with a huge warning "don't call this function if you don't know what
> you are doing"?
>
>
> * Access to some specials features from a specific Phonon backend
>
> Even if it's dirty. It's MY app, it does not affect others apps.
> I can need to access these features for various reasons: debugging,
> testing, very specific features needed by my app, very interesting
> innovations from a backend...
> And maybe if the "specials features" are interesting/needed by other
> apps, then integrate them into a nice Phonon API extension.
> Otherwise, how do you test new features that will come overtime and
> integrate it into Phonon API?
> I hope that Phonon API will involve and improve in the future, reflect
> improvements from the multimedia area. How do you think Phonon will
> address innovations that will come? Who knows what innovation will
> come next? Is it that hard to my Phonon flexible? is it against who
> knows philosophy?
>
> What is the cost of providing:
> QObject * Phonon::getInternalBackend()
> again with a huge warning "don't call this function if you don't know
> what you are doing"?
>
> Even if I know that MY code will be difficult to maintain and is
> dirty; I need it, otherwise I don't even get the features my users
> need. I don't do this "just for pleasure"!
> Others devs that only use Phonon::playSound() don't care that MY code
> can be dirty!
>
>
> What is the point for me coding VLC/MPlayer backends on my spare time,
> get my girl screaming after me being behind my screen... if I cannot
> even choose the VLC backend or access advanced subtitles features from
> MPlayer for my advanced video player?
>
>
> * Example
>
> SMPlayer is a nice piece of software http://smplayer.sourceforge.net/
> Developed in Qt4 and multiplatform. By many ways it surpasses VLC GUI.
> Ricardo Villalba spends a lot of time developing this app, and I thank him.
>
> Problem is that SMPlayer is dependent from MPlayer process.
> So I proposed him to create a VLC and a MPlayer Phonon backend and
> then integrate it into SMPlayer.
> Then he gets a clean separation from the backend and the GUI via a
> very nice API: Phonon + possible to choose another backend + others
> apps like Dragon Player can use VLC/MPlayer Phonon backends
> He is helping me by providing a libsmplayer that will be the base of a
> MPlayer backend.
> But he might want also to test and provide specials features from MPlayer.
> He might also improve Phonon as innovations are going on.
>
> Dragon Player experience also proved that it is sometimes necessary to
> access the internal backend
> cf
> http://lists.kde.org/?l=kde-multimedia&m=120663960520654&w=2
>
> Can we remove the lock and let innovation go as it should?
I strongly disagree with you because imho the idea of phonon is that you gave 
him a file and he return a stream. that's it. If you want use vlc and not 
other backends, why use phonon and not the libvls api?
Another thing: now dragonplayer use xine only for the DVD's menu, for all the 
other stuff it use phonon; and when phonon will support correctly the DVD's 
menu, dragonplayer will leave completle xine.

-- 
Fabio Alessandro Locati
-------------- 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/20080329/87172035/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia