Some general issues with Phonon...

[Tanguy Krotoff]

thx for your fast reply

>  > (btw MPlayer backend start to be nice: audio channel support already
>  > and subtitles are on the way)
>
>  great! BTW, would you be interested in hosting your code in KDE's svn repo?

I though about it. For the moment I'm happy with Google hosting (svn).
phonon-vlc-mplayer is still a work in progress, with an external
hosting I can do my dirty stuffs without disturbing others.
VLC devs propose me also to host the backend.
Here is the thing: I noticed that there is a lot of common code
between VLC and MPlayer backends. I don't like copy/paste so I merge
them using a few #ifdef + specialized classes like MPlayerMediaObject,
VLCMediaObject...
The question might rise again in the future, when phonon-vlc-mplayer
is stable and tested enough.

>  I have a local patch to rename all AudioStream occurences to AudioChannel. Do
>  you agree with that naming?

Sure.
Also I've noticed something not "symmetric" is the API:

	//MediaController signals
	virtual void availableSubtitlesChanged() = 0;
	virtual void availableAudioChannelsChanged() = 0;
	virtual void availableAnglesChanged(int availableAngles) = 0;
	virtual void availableChaptersChanged(int availableChapters) = 0;
	virtual void availableTitlesChanged(int availableTitles) = 0;
	virtual void angleChanged(int angleNumber) = 0;
	virtual void chapterChanged(int chapterNumber) = 0;
	virtual void titleChanged(int titleNumber) = 0;

You have availableChaptersChanged() with a parameter
But availableSubtitlesChanged() doesn't have it. Without the parameter
might be better.
The int parameter is useless since you have to use
QList<Phonon::AudioStreamDescription>
Also, chapterChanged(int) and friends can be probably replaced with an
API consistent/symmetric with audioChannels and subtitles .

Your decision, you know better Phonon than I :)

>  Actually the main reason there is bad support for using Phonon code (other
>  than libphonon) outside of KDE is that there's nobody working that way.
>  Trolltech has libphonon and their three backends integrated in their
>  buildsystem and the tests were built using KDE infrastructure.
>
>  So yes, patches to make that code more useful are very welcome.

I will send patches, I start to be an expert with ifdef KDEstuffs :p
Don't know when as I have a lot of things to do

I think Phonon should be a Qt based library more than a KDE library.
As a Qt library I think Phonon will get more visibility and will be
easier to use for other devs.
I found on some French forums, people trying to use MPlayer and VLC with Qt cf:
http://doc.qtfr.org/post/2007/03/21/Un-conteneur-pour-MPlayer-utilisation-de-QProcess
http://doc.qtfr.org/post/2007/02/21/Integration-de-VLC
Qt releases won't probably match Phonon releases and these devs might
be interested having the last Phonon releases. If it is easy for them
to use/compile/deploy Phonon, they will use it, test it, debug it,
even send patches and so.
Have you ever though about totally removing Phonon from kdelibs?

>  > - Impossible to use KDE-Phonon without instantiate KApplication
>  > I have to #ifdef my test apps to replace QApplication by KApplication
>  > otherwise KDE-Phonon doesn't start
>  > Is there a simpler way to solve this?
>
>  That would be a bug. Or what exactly do you mean by KDE-Phonon?

KDE-Phonon: Phonon that comes with KDE (Qt-Phonon = Phonon that comes
with Qt 4.4)
I'm using Ubuntu Hardy with KDE-4.0.3. I didn't try with KDE svn so it
might be fixed now...

>  > - Seek is not smooth
>  > When the user moves the seek bar, it sends a lot of
>  > MediaObject::seek() to the backend + the backend sends a lot of tick()
>  > signals making the seek bar behave choppy.
>  > I checked several media player and here is how some of them work
>  > (winamp, smplayer...):
>  > - user moves the seek bar
>  > - media continues to play as before
>  > - user release the seek bar (MouseRelease event)
>  > - then (and only now): send a seek()
>
>  SeekSlider::setTracking(false)

I tried this, I don't remember why but it think it was a half
solution. I have to test it again in order to tell you.

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