[gst-devel] empty buffers & GST_BUFFER_FLAG_GAP

Stefan Kost ensonic at hora-obscura.de
Tue Jan 24 14:23:13 CET 2006

Hi Jan & Wim,

any ideas/updates of how to handle these with your design?


Jan Schmidt wrote:
> On Wed, 2006-01-18 at 21:00 +0100, Stefan Kost wrote:
>> Hi Jan & Wim,
>> Jan Schmidt wrote:
>>> On Wed, 2006-01-18 at 17:36 +0100, Stefan Kost wrote:
>>>> I think there are use-cases for both applications. I'd like to read your design 
>>>> document and then continue the discussion.
>>> I just added a first draft of the idea in
>>> docs/design/part-sparsestreams.txt (in core)
>> I've just read
>> http://cvs.freedesktop.org/gstreamer/gstreamer/docs/design/part-sparsestreams.txt?view=markup
>> Thanks for adding my use case to it. Still I don't see how it will work. Imagine 
>> the following pipeline:
>> simsyn ! echo ! audiosink
>> simsyn is somthing like audiotestsrc, but instead of a freqeuncy you give it a 
>> musical note (c-3). The note will be set via GstController from time to time. 
>> Setting a note also triggers simsyn volume envelope. In the _create() function 
>> simsyn checks the envelope level before rendering a buffer. Whenever the level 
>> go close to zero it just create silent buffers (avoid calculating sines etc.).
>> Next in the pipeline is the (imaginary) echo element. An echo is usaly 
>> implemented by using a ringbuffer, where data output-data gets feedback into the 
>> ringbuffer. This produces decaying echos.
>> When simsyn determines it produces silence, I still want echo to be called, as 
>> echo still has data to produce. When echo finds out that the output level from 
>> the ring-buffer goes below zero it can mark output as silent too and remember 
>> the state. If next silent buffer are comming, it can just output silence too.
>> I don't know if this can be done with the technique you've described in the 
>> part-sparsestreams.txt. Unfortunately I don't know about the 'SCR in MPEG data' 
>> so I can't map the 'for audio, 3) is the same case as in 1)'.
> In MPEG, SCR just represents the 'current time' of the stream. In your case, once the source knows that
> it will be producing silence until time 'n', it can update the start
> time of the segment to time 'n'. The echo element can handle that by
> outputting all data until that time. 
> Hopefully that makes it clearer? I updated the sparsestreams.txt
> slightly to try and clarify that point.
> J.

More information about the gstreamer-devel mailing list