[gst-devel] question re: buffer handling

[Erik Walthinsen]

On Fri, 30 Aug 2002, Joshua N Pritikin wrote:

> Eh?  i would expect tee to emit the original stream unchanged (read/write)
> and any copies of the stream marked read-only.  So the first pad connect
> to a tee is special (r/w), but doesn't that make sense?

Ideally, every element that plans to modify a buffer in place will call
gst_buffer_copy_on_write().  The default behavior of the tee element is
then to simply increment the refcount for each extra output and send the
same buffer to all downstream peers.  The buffer is then implicitly
(explicitly?) read-only until the refcount drops back to 1.  As elements
need to modify their "copies" in place, they CoW them at that point, so
the buffers only get copied when necessary.

The efficiency of the _copy_on_write() function is pretty high in the
usual case, and if we deem it important we can make it a macro/inline-func
with a slowpath, where the macro only calls the slowpath function when the
refcount is greater than 1, bringing that one check inline.

It's worth having the option for the tee to simply copy every buffer no
matter what, but that would be very rarely used, since the
_copy_on_write() calls would occur anyway.

Actually calling _copy_on_write() is yet another in a relatively long list
of things that all plugin-writers should check off for each plugin they
write.  Is there any such list anywhere in CVS that can be worked from?

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_