Re: Introducing Muine, Rhythmbox in 2.8 and other things

A Sex, 2004-05-07 ās 22:10, Ronald Bultje escreveu:

> "Changing streams is relatively slow, it usually takes ~ 1 second, whereas
> this is more or less instant using xine-lib. This has a major impact on
> the user experience."
> If you want to know a possible way to fix this: you would basically need
> to "queue up" the next/previous song to prevent this. The GStreamer model
> focusses on playback of a single media stream. Playlists are basically on
> the border of GStreamer's core scope, probably right outside it. Queueing
> up means that you already create a pipeline element (or whatever
> descendant of that you use in Muine) of another song, if possible with a
> queue between the decoder (or the autoplugger) and the audio sink element.
> Set the left part (before the queue) to playing, and possibly wait for the
> 'full' signal on the queue. Then set back to pause (saves CPU cycles). Set
> back to playing if you change songs. Now, the transition will be instant.
> It probably sounds hackish. Sorry for that. I don't think there's an easy
> solution. Autoplugging just isn't fast enough yet... :-(.

  How about just keeping the same pipeline, and merely changing the
location attribute of the vfs source element?

  OK, I realize this will fail if one changes from a mp3 to vorbis
file.  So instead of this, we would keep a set of cached pipelines, one
for each MIME type encountered so far, and simply switch pipeline and
file location as needed.  It probably isn't as instantaneous/smooth as
xmms with cross-fading plugin, but should be a lot faster than 1 second.
  Well, I really know very little of GStreamer programming, so forgive
any technical errors.

Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]