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

List:       kde-devel
Subject:    Re: State of the Noatun
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-10-24 21:10:22
[Download RAW message or body]

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.

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

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

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

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