[gst-devel] empty buffers & GST_BUFFER_FLAG_GAP

[Wim Taymans]

On Wed, 2006-01-18 at 13:53 +0100, Stefan Kost wrote:
> Hello Wim,
> 
<snip>

> >>Is that what GST_BUFFER_FLAG_GAP is for? If not, may I also add
> >>GST_BUFFER_FLAG_BLANK. As part of the proposal I would update GstVolume,
> >>GstLevel, GstAdder and GstAudioconvert to make use of that.
> > 
> > The GAP flag was added to notify elements that this buffer was generated
> > by some element to indicate that this buffer was inserted into the
> > stream to fill a gap. Audiorate for example sets this flag when it needs
> > to insert buffers to make a perfect stream. Not sure why we would ever
> > need this, it was a feature request from Thomas, I'm sure he has a use
> > case somewhere.
> 
> I grepped the whole source tree and found no reference to those flags.
> So its probaly unused. If nobody knows otheriwse I will mark it in the
> source with a (FIXME).

Hmm.. ok
> 
> > There is a related FLAG_PREROLL that is actually made to mark buffers
> > that should not be processed or rendered. Its name is probably wrong,
> > though, but could be used to mark useless buffers.
> > 
> >>What do you think about it?
> > 
> > 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.  
           
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.


Wim

> 
> > Wim
> >>Stefan
> >>
> Stefan
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>