[gst-devel] pull()ing buffers backward

[Erik Walthinsen]

(disclaimer: I managed to write about 6 lines of code today, so if this
gets incoherent, it's because I've been generally hosed today)

OK, I've read through the code to handle passing buffers backwards from
sink to source, but only after completely obliterating it ;-)  The pull()
function was intended for scheduling operations initially, so when I did
the bit to get coroutines working I commandeered it.  I shall remedy that
by (now that I know how it all works) modifying the specifics of the
mechanism so as to leave pull for the backwards passing of buffers.

As for the backwards pull mechanism itself, it looks good, but I've got
some ideas that will hopefully make things better.  The main constraint in
the way things are implemented currently is that the provider of the
buffer must be immediately connected to the consumer that's aware of the
concept (that's another thing, I think this should be intrinsic to
gst_buffer_new() if at all possible).  A scenario where you might have
some intervening element is an in-place effect between an mp3 decoder and
the audio sink, or the equivalent in video.

What this means is that any element that's specifically designed as an
in-place modifier should set some capabilities bit in its class (or more
likely the instance, since the choice of parameters to the element may
make it in-place or not).  Then at plan generation (which is done to a
small extent right now, moreso with coroutines, and even more so as these
things grow) bits are set and pointers are copied so that the buffer is
requested from the providing sink as early as possible.

In the in-place audio effect example, plan generation could copy the
pull() pointer from the audiosink's sink pad to the pull() pointer of the
effect's sink pad, and set a bit to keep track of the fact that it's not a
natively provided function (i.e. the effect didn't provide it).  Then
when the time comes for the mp3 decoder to ask for an output buffer, it
asks its immediate peer for one and 'inadvertantly' asks the audiosink for
it instead.  Similar to th chain-function copying that is done.

I suppose I should write up something on coroutines and the plan
generation concept.  I'll see if I can hack something up tonight.

         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