[gst-devel] neutral buffer handling in sparse streams

Steve Fink sphink at gmail.com
Wed Oct 3 22:59:49 CEST 2007


That works for me, as long as it is valid to ignore the flag. (You
could imply with the flag that the use of any such buffer's contents
is invalid, but I don't like that because it would force all elements
to handle the flag specially rather than relying on their default
behavior to be about right, modulo losing out on potential performance
gains.)

But I thought there was an initial objection that _GAP might mark a
buffer with important filler information, in which case discarding
such a buffer (in a mixer, for example) would be invalid. Defining the
semantics to mean "no relevant data" prevents that usage. Personally,
I think it sounds like such a niche case that I don't care, but is
everyone ok with it? (Or is "everyone" == "wtay, 'cause he has a
commit bit and owns this sort of thing"?)

Btw, my element will be producing these buffers in the next recompile,
and I'm perfectly happy with the proposed new semantics.


On 10/3/07, Wim Taymans <wim.taymans at gmail.com> wrote:
>
> 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
> > >
>
>




More information about the gstreamer-devel mailing list