[gst-devel] question re: buffer handling

[Richard Boulton]

On Thu, 2002-08-29 at 17:27, Thomas Vander Stichele wrote:
> 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 ?

Surely, if the refcount is 1, there should be no other references to the
buffer.  I havn't looked into the refcount system used here, but it
would be very surprising if a refcount of 1 didn't imply that no other
piece of code has a reference to it.

Of course, it's always possible that your code will take a copy and thus
increase the refcount.  But that's under your control.

So, I'd say "no, there shouldn't be situations where some other part of
the system could ref the buffer if the refcout is 1".  Someone more
familiar with the code feel free to correct, and surprise, me.

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

I think so.  "gst_buffer_make_writable()" or something.
It should probably be able to take a readonly buffer and return a
writable copy, too.

> > 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 think it makes the code easier.  Any plugin that wants to modify a
buffer simply calls gst_buffer_make_writable() on it first, and has
nothing further to think about.  At no point do coders have to worry
about making copies of buffers readonly, or whatever.

Making tee return readonly buffers is a quick hack IMHO.  Quick hacks
take longer to sort out in the long run.
 
> 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 ;)

I think it's always been implicit in the API that if a buffer is
writable and is modified then other copies of it will be changed.
Documenting this clearly, and how to deal with it if you need to have
separate modifiable copies, is all that needs to be done.

Making a helper function would be the best way of helping plugins to
deal with it, and doesn't break compatability with old plugins (though
new plugins won't work with the old core).  Add that now, too, I say.

I'll shut up now, since I'm not about to write some code. ;-)

-- 
Richard