[gst-devel] Signals and parsing of files...

Wim Taymans wim.taymans at chello.be
Wed Mar 7 17:42:13 CET 2001


On 07 Mar 2001 14:51:01 +0100, Thomas Nyberg wrote:
> Image the case where you want to play only a portion of a file. You 
> want to start right in the middle. How can this be done?
> 
> Does there already exists an easy way of starting playing at
> arbitrary positions? Or is it a feature yet-to-come?
> 
> 
> Most formats have a header containing information about the 
> data in the file. The depth, rate, sample-size and so on.
> But, this header would be lost if you simple seeked to the middle
> and did nothing more.
> 
> Somehow, you need to feed the parsers enough data for it to be able 
> to determine this information about the audio. Then do the seek-
> operation.
> 
> One way, would to define a signal that gets emitted when a
> parser/decoder/encoder has enough information for it to be able
> to decode/encode the stream. However, there still exists an issue
> with the amount of information sent to the parser. Too much or too 
> little would not be good.
> 
> To start playing in the middle, one could connect to the signal
> described above, and then do a flush/seek-sequence to the 
> position in question. But that looks a little bit ugly from
> my point of perspective. There should be a much nicer way
> of doing this. I am sure someone here have thought about it,
> or is thinking about it.

Indeed. As far as I understand what Omega and RR are up to, seeking
operations 
are performed by the parser elements when they receive a 'seek' event. 

When the apps want to receive a data buffer for time X (an audio buffer
to be played 
at time X), a seek event is going to travel from sink to src. The parser
element 
(mp3parse) will have a handler for the event and will pull the relevant
buffer from to 
sinkpad. Imagine the case of a WAV file, where the parser first has to
read the 
header, it'll first pull the header (offset 0 or so) and then pull/push
the requested data.

The point is that the seeking operations are most likely be handled by
loop-based 
elements that can intelligently perform random access _get_region calls
to the peer
elements. The TimeCache will also provide a way to cache the offsets so
that seeking
can be done more efficiently.

Wim 

> 
> 
> /Thomas <thomas at codefactory.se>
> 
> -- 
> Thomas Nyberg                    thomas.nyberg at codefactory.se
> CodeFactory AB                   http://www.codefactory.se/
> Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel





More information about the gstreamer-devel mailing list