kretz at kde.org
Sat Nov 11 15:48:41 GMT 2006
thanks for the nice feedback!
On Saturday 11 November 2006 13:06, mETz wrote:
> Some things I stumbled over so far:
> - initial Phonon::State is LoadingState, either the docs are misleading or
> a state is missing (i.e. "nothing playing and nothing loaded"-state).
That got me thinking. I discarded the NoMediaState (or whatever you want to
call it) because I thought it wasn't needed as it's not much different from
But there would be one good use for the NoMediaState that would solve a
problem: Currently when a MediaObject finishes it will go into StoppedState
and the API allows you to simply call play() again. This is suboptimal for
the case where MediaObject transparently uses KIO to feed the data to the
backend, because: what should it do at the end? Restart pre-buffering or wait
with buffering until play() is called as in most cases a MediaObject will be
played only once. If MediaObject goes into NoMediaState when the finished()
signal is emitted that would solve the problem...
I think this was discussed before - somewhere... can't find it though.
> - seeking results in audio-blips, could this be suppressed with a
> fade-effect as implemented in aKode?
That's a Xine issue, which should be fixed in libxine. You can probably also
add a workaround in the xine backend, but that's low priority at the moment
as the backend first needs a (almost) rewrite because of the frequent
deadlocks in libxine. :-(
> - calling mediaobj->setUrl() with a shoutcast-url seems to connect
> immediately, not only after calling play(). Unfortunately calling play
> several seconds after setUrl() does not work properly then, sometimes
> resulting in crashes which I couldn't reproduce properly yet. Furthermore
> phonon goes into BufferingState after the setUrl() call, I'd expect that to
> happen after play()
Right, that's a bug in phonon-xine. After setUrl() it may only go from
LoadingState to StoppedState. setUrl calls xine_open which apparently
connects and sends XINE_EVENT_PROGRESS events. The handling of those events
is not implemented correctly, yet.
> - video output does not work at all here and hangs my app on resize. This
> could be related to:
> "phonon (xine backend): WARNING: No xine video output plugin without
> XThreads found. Expect to see X errors."
> Kaffeine works fine though, maybe it has to do with xine-config, I have no
> idea :(
Right. That's stupid libxine calling X from multiple threads. If you have
libxine 1.1.2 you can try the hacked videooutput plugin in
phonon-xine/xineplugins/videoout. A correct solution is to implement a video
output plugin that synchronizes the X calls to the GUI thread. :-(
> - SeekSlider does not offer QSlider API and is a bit inflexible, the same
> probably applies to VolumeSlider
Right. But how much of the API should really be offered? If you want to seek,
get the position or get/set the volume you use the
AbstractMediaProducer/AudioOutput API. If there's something you need it can
easily be added the the classes. Let me know.
> - SeekSlider seeking on a mousewheel-event seems to be < 1sec
Right, I haven't considered wheel events. Meaning there's no special code -
it's pure QSlider behaviour.
How do you think it should behave?
> - playing shoutcast-streams results in excessive debug-output about buffers
> (not grave but annoying if you're interested about other debug messages)
As you can guess from above comments about phonon-xine I had major headaches
with libxine... But you can simply turn of debug area 610, and disable xine
debug in phonon-xine/backend.cpp:54
Matthias Kretz (Germany) <><
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
-------------- next part --------------
kde-multimedia mailing list
kde-multimedia at kde.org
More information about the kde-multimedia