[gst-devel] [Gstreamer-openmax] how to pass custom metadata between gst elements

[Rob Clark]

On 06/29/2010 04:30 PM, hd d wrote:
> thanks for the response - yes - i am referring to linux - can you give 
> a more detailed call flow on what happens in user space and kernel 
> space. How does sink element pass memory region to decoder element in 
> user space? omx decoder element needs an fd, offset, length to mmap 
> framebuffer memory into user space or does this all happen in kernel 
> space without any intervention in userspace/framework. This applies to 
> use cases like camera v4l2 src sending data to omx video encoder in 
> gst framework. if camera and omx vid enc need to share the same 
> physical memory, additional information about memory region (like a 
> buffer identifier or fd) needs to be exchanged between user space 
> elements in gst.

typically the decoder would not care too much about *where* the sink got 
the memory.. but would just use pad_alloc() to allow the video sink 
element to allocate memory which the video sink thinks the decoder 
should decode into..   some video sinks (for example, v4l2sink or 
omapfbsink) will mmap buffers into userspace, and then pass this to the 
decoder.  But normally the decoder doesn't need to know which fd was 
mmap'd, the offset, etc.  But if your decoder requires physically 
contiguous memory, with no possibility to remap virtually contiguous 
memory, then it possibly gets complicated.  (Not to mention, various 
useful elements for debugging, like filesink, won't work to well..)

btw, v4l2src (camera/encode) might be a bad example.. since what is in 
gst-plugins-good doesn't support pad_alloc() / USERPTR.  So it allocates 
it's own buffers.  But there are other camera elements which do a 
similar thing to what you describe, doing pad_alloc() to allocate 
buffers from the display, which then get sent to both encoder and sink 
element.

BR,
-R