[gst-devel] Re: bufferpools

[Ronald Bultje]

Hi Dave,

On Fri, 2004-01-09 at 02:12, David Schleef wrote:
> On Fri, Jan 09, 2004 at 02:00:24AM +0100, Julien MOUTTE wrote:
> > so basically a first thing to do would be to implement bufferalloc in
> > ximagesink, that would be transparent and unused for the rest of plugins
> > and then implement the gst_pad_alloc_buffer in possible peers of
> > ximagesink such as ffcolorspace, videoscale, videotestsrc etc..
> You speak only the truth.

But if the peer doesn't provide a bufferalloc function or it returns
NULL, I assume the default is used, right?

> By the way, the offset parameter should be GST_BUFFER_OFFSET_NONE,
> unless you're outputting to filesink, in which case it should be the
> offset in the file.  (Yes, this is disgusting.  This could be solved
> by "transient" buffers (buffers that can't be held between iterations),
> but it may require subtle changes to a few, as yet unknown, elements.)

I don't think we'll need this. At best for direct output of encoded
data. Now imagine a muxer like avimux. Only when it has actually pulled
data from the encoders, it will decide which buffer/pad to parse to the
file next. This means that by principle, avimux will never provide a
bufferpool. I think this goes for most elements, except single-input
muxers (wavenc) or direct encoding to file (lame), where I think the
datarate really is an issue. We don't actually implement mmap()-based
output in filesink anyway.

Of course, it's a fun idea, but is it worth the hassle for that little
gain? :).

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer