[gst-devel] question re: buffer handling

[Thomas Vander Stichele]

> On Thu, 2002-08-29 at 15:59, Thomas Vander Stichele wrote:
> > > Since buffers are reference counted, you could use that to see if you
> > > are the only one holding a reference (I think). 
> > 
> > Yeah, theoretically, but this could get nasty very quickly.  I don't know 
> > if it's safe to use the reference count for this, and you'd probably have 
> > to do locking for it to work.
> 
> How about making a helper function which takes a buffer and returns a
> buffer which is safe to modify.  This function would work by getting
> appropriate locks, checking the buffer reference count, returning the
> same buffer if the refcount is 1 (so noone else is looking at the
> buffer), or taking a copy of the buffer if the refcount is 0.

Maybe the lifetime of a buffer should be more clearly documented.  For 
example, is it guaranteed that if the refcount is 1, no other part is 
still able to get a ref to it ? ie, are there situations where some other 
part of the system could ref the buffer, expecting it to be the same as it 
was originally, while some plug-in modified it in-place ?

> Then, before an element modifies a buffer, it should _always_ call the
> helper function to get a buffer that's safe to modify.

> I'm not sure that having a special flag to set is as useful as having a
> function to call: perhaps the element only occasionally wants to modify
> a buffer, but normally passes through, for example. (For example, an
> element which does a fade out at the beginning and end of a song, but
> passes buffers through unchanged otherwise)

Hm, good points.  The overhead of either a flag or this extra function is 
about the same.

So, should I be adding this function ? What should it be called and where 
should it go ?

> The problem with a tee simply marking all its buffers readonly is that
> you then force all the buffers to be copied, instead of allowing the
> final one to be used without copying it.  In other words, you force an
> extra buffer copy.  I'm not sure how important this is, but it would be
> nice to avoid it.

Yeah.  It makes the code harder though.  For now I just want to add some 
bits that
a) solve my problem at this point, so I can run my app based on the next 
gstreamer release
b) are extendable to do the right thing in the future, without having to 
change the API.

I'd like to do this quickly and before the next release, so I can update 
all the filters I've written to take this into account, so they're 
actually usable ;)

Thomas

 -- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
I love the way you love
but I hate the way
I'm supposed to love you back
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/