[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: State of the Noatun
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-10-24 21:31:47
[Download RAW message or body]

   Hi!

On Wed, Oct 24, 2001 at 11:10:22PM +0200, Martijn Klingens wrote:
> On Wednesday 24 October 2001 22:40, Charles Samuels wrote:
> > 3) Video Embedding
> >
> > I have a game plan for this.  Stefan's main problem with noatun is the
> > "multiple-interface" thing.  My solution is that each plugin can inherit
> > from a, say, VideoWidget (more or less) which will use the arts interface
> > to reparent the video window.
> 
> I would very much like this widget to be part of a libkdemultimedia, so 
> application programmers can just include the proper header. Same for some 
> audio playing code (engine.h/engine.cpp springs to mind).
> 
> An alternative would be the kaboodle part. Then the Kaboodle part should 
> inherit from a common interface (preferably in kdelibs).
> 
> I am proposing this, because having to program aRts directly might be fun for 
> audio apps but is quite a big pain for an app that 'just' needs to play a 
> simple playobject and doens't require much more than basic start/stop. A 
> QObject/QWidget based class is very much wanted there. Kaboodle part already 
> offers that, but it is not standardized in its interface.

I think libartskde would be the right place to put this. We already have other
aRts <-> Qt stuff there, like KArtsWidget (which you can use to embed aRts
effect dialogs into your apps), so I think putting the video stuff there would
be a good idea.

> > 6) Streaming
> >
> > I managed to get streaming to work.  However, I uncovered a flaw in the
> > KPlayObject design: The serious lack of buffering; it's downright awful. 
> > It skips like you wouldn't believe, with low or large amounts of simple
> > load.
> 
> To my big disgrace I discovered the same. Also, last time I checked the 
> stop() call in kaboodle's engine.cpp didn't work, because it tried to seek, 
> which is obviously unsupported on streams. If this is not fixed yet it should 
> at least close the stream's connection and terminate the sound. But I guess I 
> should bug Neil with that or fix it myself.

You should have a look at where exactly the problem is. Seeking on streams
is basically supported by our interfaces (like: Arts::FileInputStream does
this), but as far as know none of the streaming PlayObjects really make use
of this, and somewhere in KPlayObject, the error message of "no seeking in
streams is generated" (which is kind-of wrong, as there is seeking in
FileInputStreams).

> > I think this is the latency from the MCOP calls of the playobject
> > asking noatun for the next download sample (the KIO request).  Stefan knows
> > about this: have you made any progress?
> 
> A configurable buffer size might be nice. On slow links it can be desirable 
> to pre-buffer 30 or even more seconds, while on a fast link a 2-3 second 
> buffer can already be enough. Also, while buffering there should be a way to 
> retrieve the buffering status so a GUI can communicate it to the user.
> 
> Just my thoughts on the subject. I haven't extensively used the multimedia 
> code yet, this is what I encountered.

Well, you need to look into kdelibs/arts/* - everything else is just using
these objects, but not adding (or removing) functionality. I think some buffer
settings especially for the KIO <-> InputStream magic are just hardcoded.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]