[gst-devel] empty buffers & GST_BUFFER_FLAG_GAP

Stefan Kost ensonic at hora-obscura.de
Wed Jan 18 08:38:03 CET 2006

Hi Wim,

Wim Taymans wrote:
> On Wed, 2006-01-18 at 13:53 +0100, Stefan Kost wrote:
>>>We're leaning towards using the segment start value to make stream time
>>>progress in the case of sparse data streams. The reason is that we
>>>effectively already use this mechanism to perform segment seeks and
>>>looping. Also most elements and filters do not need to bother at all
>>>with checking buffer flags and can just use the existing segment event
>>>code without any change.
>>>The only addition needs to be done in mixing/muxing elements (adder) so
>>>that they know that they should not expect data on a pad with timestamps
>>>before the updated segment start.
>>I understand that from the a processing elements pov. They won't notice
>>that they were not given all buffers, Wouldn't that cause a problem for
>>elements like an audio delay or the level element. An audio delay would
>>not be given a chance to flush its ring-buffer and the level element can
>>not slowly release the levels.
>>Using zero'ed buffer this would work. Its up to the element to make use
>>of the buffer-flag. Ideally those zero'ed buffers would be static, so
>>that for a longer perio of silence, we don't alloc empty memory again
>>and again.
> Elements that don't respect segments when they should are going to fail
> in many places. Consider the case of a typical media file, suppose it
> contains 4 seconds audio and 5 seconds of video. A newsegment is sent on
> audio and video pads notifying downstream that time will go from 0 to 5
> seconds. After 4 seconds, no audio is outputted by the decoder anymore.
> When the media file is looped, a new segment is sent on both audio and
> video pads. Both pads will know that the previous segment lasted 5
> seconds and the second run of the loop will therefore run synchronized.
> There was no audio data between second 4 and 5 though. An audio delay
> placed after the audio decoder would therefore not receive any data,
> upon reception of the newsegment (or EOS for that matter) it can however
> know that there is a piece of audio missing and can flush its buffers
> pretending silence happened for that time. This is for example exactly
> whay audioresample does on both EOS and newsegment since it buffers data
> and needs to drain on EOS and complete the segment before starting the
> new segment. Elements that don't buffer do not have to bother at all.  
I belive we a re talking about two different things here. I totaly agree that 
when seeking or looping, elements such as level or an echo-delay should flush.
But in the case I am interested in there is no real discontinuity, just silence.
Thus the echo-delay can echo out and the level analyser can decay.

Is your design document available somewhere? What I don't yet understand is how 
a source will behave in you design. In my case whenever an element (source or 
processing element) determines that the output buffer would be blank, if would 
flag the buffer as such. An element might know this in advance (volume with 
gain=0.0). It would then produce and emptied buffer and flag it. In voip apps 
there might be a noise-gate which scanns incomming buffers and flags those which 
are empty.

> We can not, as an alternative, reasonable expect all streams to be made
> non sparse by every element (decoders should then fill the segment with
> empty buffers even if the segment stop is unknown). The newsegment and
> EOS events are sufficient to give enough information about elapsed time
> and are more efficient than doing data passing.
I think there are use-cases for both applications. I'd like to read your design 
document and then continue the discussion.

> Wim

More information about the gstreamer-devel mailing list