mETz81 at web.de
Sat Nov 11 16:44:11 GMT 2006
On Saturday November 11 2006 16:48, Matthias Kretz wrote:
> 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
> the LoadingState.
> 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.
I'd think that buffering should not occur at all before play() gets called.
I'd expect that if the engine is stopped and I call setUrl() that it simply
remembers that Url and maybe already checks if it supports that type of url
(think about unsupported protocols). Apart from that it should not do any
buffering, opening, loading, whatever.
so you have something like:
EmptyState -> (setUrl() call) -> StoppedState -> (play() call) ->
BufferingState -> PlayingState -> (stop() call) -> StoppedState
> > - 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. :-(
found the plugin after I wrote this mail. Works fine here :)
Btw, does the VideoWidget handle calls like hide() and show()? I'm thinking
about using a QStackedWidget with one widget for video-display and one for
audio-display (maybe with vis, maybe metadata, unsure about the look as of
> > - 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.
I would hand-through the following properties:
tickInterval : int
tickPosition : TickPosition
pageStep : int
singleStep : int
tracking : bool
These should not interfer with what you're doing with the slider inside the
class, but they allow changing the look and the amount for seeking using
> > - 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?
I think it uses pageStep for wheel events.
Btw, if you have some time then don't forget to stop by at #kde-multimedia ;)
I'd also be interested in improving the avKode backend. aKode is still working
well with Noatun here so I think avKode could be the better backend-choice if
it'd be more complete :)
Bye, Stefan aka mETz
-------------- 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