[gst-devel] Query regarding GstPadBufferAllocFunction for allocating physically continues mem

[David Schleef]

On Tue, Mar 27, 2007 at 04:40:34AM -0700, Kugan V wrote:
> [Sending this again from subscribed e-mail. Sincere Apologies if the
> other mail also reaches the list]
> 
> Hi All,
> I have a hardware implementation of a filter and need to write a gsteramer
> wrapper for this work in a gstreamer pipeline. As a first step, I want to
> test
> this on a  gstemare pipeline witth videotetsrc -> filter ->tvout. Here
> filter
> and tvout are hardware modules for which I will be writing the gstreamer
> plugins. However, in doing this I have run into following problem:
> 
> 1. I need to allocate physically continuous memory such that the hardware
> modules can do DMA on them. In this regard, I tried writing a
> buffer_allocation
> callback (with gst_pad_set_bufferalloc_fuction) for the filter sinkpad. If
> id this,
> can I assume that the GstBuffer pushed by videotestsrc will be allocated
> using this? If not how do I do this?

No, you cannot assume this.  You must check that it's a buffer that
was allocated using your bufferalloc function, and if not, you
probably will want to allocate a new buffer and memcpy the data into
it.  You might want to look at xvimagesink to see how it does this
with XShmImages.

> 2. the callback function has the prototype
> GstFlowReturn (*GstPadBufferAllocFunction)  (GstPad *pad,
> guint64 offset, guint size,  GstCaps *caps, GstBuffer **buf);
> In the callback function, I am doing the follwing
> a. malloc memory for GstBuffer structure

GstBuffers are created by calling gst_buffer_new().  If you decide to
subclass GstBuffer (as in xvimagesink), you will probably implement
your own _new() function that calls gst_mini_object_new().



dave...