[gst-devel] Re: Pull functions

[Erik Walthinsen]

On Sun, 16 Jul 2000, Wim Taymans wrote:

> I was reading about the comments you made on the website about pulling
> buffers.  I agree we should provide backward pulling with
> gst_buffer_new().  The problem is that if the element does a "buffer
> pull" a lot of meta data has to pass with it so that the element can
> fill the buffer with the correct data. If the element cannot do that it
> has to create another buffer. This means that the element *should* know
> about the fact that the buffer has been pulled. 

One method I was using in a previous incarnation was a buffer pool. 
Buffers are allocated out of a pool, using block allocators for
efficiency.  I actually wrote quite a lot of code along those lines, but
then realized that most of the block allocation stuff is kindof a waste of
time.

Regardless, a buffer pool setup could be used, such that an element can
query it's successor in the pipeline for a pool, and use that.  A smart
element would have a private cache of this pool pointer, which would start
out as NULL.

If gst_buffer_new() is passed a non-null pointer, it would call the
function provided by the buffer pool, which would typically be supplied by
the element that created the buffer pool.  This may pass back a buffer
with metadata already attached, etc.

Where it gets a little interesting is if you're not immediately adjacent
to the potential buffer supplier, and all intervening elements simply
modify the data in place (like an EQ).  In that case you definitely want
to still get the buffer pool from the final sink.  For this to work, the
function that queries for the existance of a buffer pool will have to have
some way of knowing to query past the next element.  My thought is to have
a collection of bits that explain some of the more fundamental properties.
In this case, said function would check GST_ELEMENT_INPLACE, and if it's
set, proceed to check it's successor, etc.  Termination conditions are
finding a buffer pool (obviously), finding a sink (NULL), finding more
than one output from an element (NULL), and finding an element that's not
INPLACE.

For elements with more than one output that are still INPLACE, it would
simply copy the pointer from the appropriate downstream (sink-side)
element.

As far as giving the element a way to tell if a buffer was 'pulled',
simply having a pointer to the buffer pool it came from would be enough.
If it's non-null, it's been pulled.

Of course, 'pulled' is now an overloaded term, being also used in the
scheduling code.  There probably won't even be an explicit name for it
once buffer pools are set up, though.  If anyone can think of a good term
to use, even though it won't go in the API, we have to document it
somehow.

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user