[gst-devel] neutral buffer handling in sparse streams

[Wim Taymans]

On Wed, 2007-10-03 at 10:18 -0700, Steve Fink wrote:
> I'm not sure if I like this suggestion, but it strikes me that by far
> the most common use case for GST_BUFFER_FLAG_GAP would be when the
> contents of the buffer really are irrelevant (or neutral, or whatever
> you want to call it). So perhaps what is needed is an extra flag to
> say that the buffer contains "gap filler" data in the less common
> cases.

Sounds like you want to redefine _GAP to mean a buffer that contains no
relevant data, which is what it currently contains (only audiorate
produces such buffers AFAIK and they contain silence) but is not clearly
stated in the docs. I'm perfectly fine with that, provided we make sure
that other data used to fill a gap (confort noise, frame duplication or
reconstruction) does not use that flag. If that's fine with everybody,
we'll do it like that and don't create another flag.

Wim 

> 
> On the plus side, this gives more information to the buffer consumer.
> So, for example, an application-aware mixer might decide to discard
> gap fillers if any input was non-gap, and keep only one of the gap
> fillers (rather than mixing all of them) if all inputs were gap
> fillers. Or whatever.
> 
> On the minus side, dependent flags are ugly. But making them
> independent (_GAP and _HAS_DATA_OF_INTEREST, maybe?) means that the
> other flag would need to default to "on" in the non-gap case, which is
> no good. Also, using up a flag for a niche case is unfortunate.
> 
> But I just wanted to throw it out there.
> 
> 
> On 10/3/07, Wim Taymans <wim.taymans at gmail.com> wrote:
> >
> > On Wed, 2007-10-03 at 08:24 +0200, Stefan Kost wrote:
> > > hi,
> > >
> > > Quoting David Schleef <ds at schleef.org>:
> > >
> > > > On Mon, Oct 01, 2007 at 10:33:35PM +0300, Stefan Kost wrote:
> > > >> So what the way to go?
> > > >>
> > > >> 1) use GST_BUFFER_FLAG_GAP and define it as such
> > > >> btw. its right now only used in
> > > >> gst-plugins-base/gst/audiorate/gstaudiorate.c to
> > > >> mark a silent filler-buffer
> > > >>
> > > >> 2) add GST_BUFFER_FLAG_NEUTRAL
> > > >>
> > > >> 3) segments
> > > >>
> > > >> 4) anything else?
> > > >
> > > > 5) Push subbuffers of a well-known read-only buffer containing only
> > > > zeros.  (Let's call it gst_buffer_zero.)
> > > >
> > > Interesting idea. We could subclass GstBuffer as GstZeroBuffer and
> > > then elements can check with GST_IS_ZERO_BUFFER.
> >
> > Problem is that not all formats of silence have 0 bytes (unsigned audio
> > for example).
> >
> > I still think a good flag that works for audio, video, text, .. is the
> > way to go. I have problems with a good name, maybe
> > GST_BUFFER_FLAG_EMPTY, GST_BUFFER_FLAG_VOID, GST_BUFFER_FLAG_ZERO,
> > GST_BUFFER_FLAG_DEFAULT?
> >
> > We don't have much space to add new buffer flags (we can add 3 more):
> >
> >   GST_BUFFER_FLAG_DELTA_UNIT = (GST_MINI_OBJECT_FLAG_LAST << 4),
> >   /* padding */
> >   GST_BUFFER_FLAG_LAST       = (GST_MINI_OBJECT_FLAG_LAST << 8)
> >
> > Another idea is to specify some format specific flags like:
> >
> >   ...
> >   GST_BUFFER_FLAG_CUSTOM1 = (GST_MINI_OBJECT_FLAG_LAST << 5),
> >   GST_BUFFER_FLAG_CUSTOM2 = (GST_MINI_OBJECT_FLAG_LAST << 6),
> >   ...
> >
> > And then define what they mean for audio/video. We could need something
> > like this to mark interlaced video frames. One of those custom flags
> > could be used to mark 'silent' audio buffers.
> >
> > Wim
> >
> > > >
> > > > I'm not recommending it, just suggesting it as an alternative that we've
> > > > discussed in the past.  It has the minor advantage of being transparent
> > > > to elements that don't know how to handle it.
> > > >
> > > >
> > > >
> > > > dave...
> > > >
> > > >
> > > >
> > -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Microsoft
> > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > _______________________________________________
> > > > gstreamer-devel mailing list
> > > > gstreamer-devel at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > gstreamer-devel at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >