[gst-devel] API freeze update

[David Schleef]

On Mon, Dec 08, 2003 at 07:30:46PM -0800, David Schleef wrote:
> >  - fix bufferpools (ds)
> 
> I have a plan for this now.

I have code for this now.

Basically, I've completely removed all code related to bufferpools in
both gstreamer and gst-plugins.  Non-trivial code was only #if 0'd,
since it will be useful later.

The pad->bufferpool function is being replaced with pad->bufferalloc.
This function is used by gst_pad_alloc_buffer(pad, offset, size), and
may be used by elements when they want to allocate a buffer to be
pushed to a particular pad.

The use of gst_pad_alloc_buffer() and implementation of pad->bufferalloc
is subject to a number of theoretical and practical rules (which
Company and I discussed on IRC today, if you want to read the log).
Most of these rules are also true for bufferpools as well, and were
generally _completely ignored_ by the code.

A pad->bufferalloc implementation will create a new buffer (using
gst_buffer_new), override the copy() and free() functions that
are in every GstBuffer, set the other details, and return it.  This
is the same technique that the efence element uses to create
Electric Fenced buffer, and very similar to what bufferpools currently
do, but without the extra API crap.

In addition, while converting plugins, I noticed that about 50% of
elements got the bufferpool implementation Just Plain Wrong.  But
that's not too bad, seeing as how it was theoretically impossible
for an element to do bufferpools 100% correctly.

Patches are attached to bug #128868.  I plan to commit this tomorrow
and implement the pad->bufferalloc functions in the next few weeks.



dave...