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

List:       kde-multimedia
Subject:    Re: Seeking in arts
From:       Martin Vogt <mvogt () rhrk ! uni-kl ! de>
Date:       2002-06-02 16:12:31
[Download RAW message or body]

On Sun, Jun 02, 2002 at 04:44:56PM +0200, Stefan Westerfeld wrote:
>    Hi!
> 
> On Sun, Jun 02, 2002 at 10:10:49AM +0200, Martin Vogt wrote:
> > On Sat, Jun 01, 2002 at 09:00:03PM +0200, Ralf Schmelter wrote:
> > >         player->play();
> > >         player->seek(Arts::poTime(10, 0, 0, ""));
> > This is too fast. The play call succeeds before the lenght
> > is known. A seek is only possible, after you have the length.
> > Reason: decoding runs in a seperate thread.
> > (We really need a unthreaded mp3 decoder,any volunteers?)
> 
> There is an unthreaded mp3 decoder in gsl (its based on libmad), along with
> an unthreaded ogg decoder. Hans Meine is currently doing a C++ wrapped version
> of this, the plan is to have a PlayObject based on this before KDE3.1. Of
> course this requires libmad then if you want to use this decoder ; and
> streaming is missing, too.
>
I think this is due to the callback API of libmad?
(I really dont like decoders which want to have callbacks.)

 
> I think the optimal way would be, long-term:
> 
> 1. besides DataHandles, put another plain C API into GSL, that can decode
>    streams
We should standarize on a push/pull API here.
push data in decoder and "on data signal" pull data drom decoder.
==> no callbacks.

Martin

> 2. implement mp3/ogg/wav decoders there
> 3. wrap those into PlayObjects as required


_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]