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

List:       kde-devel
Subject:    Re: State of the Noatun
From:       Charles Samuels <charles () kde ! org>
Date:       2001-10-24 21:12:43
[Download RAW message or body]

On Wednesday 24 October 2001 02:10 pm, 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.
>
> Since you are (together with Stefan and Neil) one of the main multimedia
> guys within KDE, I'd like to hear your thoughts on this.

The main reason engine.cpp and player.cpp havn't been moved to libnoatunarts 
is that both of them depend on other parts of noatun to function.  And if you 
need your own media player, you can just use the kaboodle kpart.

In any case, noatun is BSD, which may explain why it's already in 3 places in 
cvs :)

>
> > 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.

Right :)

>
> > 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.

Well, obviously we should buffer.  That's a given.  The problem is _how_.  
And only Stefan can answer this.




 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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