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

[Felipe Contreras]

hdandroid at gmail.com wrote:
> New to gst - need some help:
> 
>  what is the best way to pass meta data from one element to the other in gst
>    pipeline?
>    example use case: in a HW accelerated transcoding session, OMX video decoder
>    output buffer is sent to OMX video encode. decoder output is present in a
>    physically contiguous memory identified by a file descriptor and encode
>    needs to use this file descriptor to derive the physical address of
>    decoder's output buffer. OMX buffer header provides platform private field
>    to carry platform specific data.
>    Gst seems to define buffer meta data but what is the best place to embed
>    this information. Does gst have any platform private/reserved fields
>    (similar to OMX buffer hdr platform private data) to carry such information?
>    http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstBuffer.html#GstBufferFlag
>    Another question is how does buffer from one element get passed to another
>    element when elements are in different processes? Or gst assume all elements
>    run in the same process.this cannot be practical scenario as usually display
>        resides in a different process.

All GStreamer elements run in the same process. The display server might
run in a separate process, but that's independent of GStreamer (i.e. the
API is X11, not Gst).

If you only want to provide custom data between two contiguous elements in the
pipeline you have two options:

 1) Provide a GstBuffer sub-type, like GstOmxBuffer. Then it should be
    easy to add any information that you want, but you should check that
    the GType is the right one.

 2) Add a custom field to the GstCaps of the buffer.

However, I don't see why you need a fd for contiguous memory. On OMAP3
platform I have simple sink element that provides framebuffer memory
(which is contiguous), and the video decoder element mmaps that memory.
At kernel level the dspbridge driver is able to identify this memory as
VM_IO, and the mmap operation is very fast. IOW; everything happens
behind the scene; at kernel level.

Are we talking about linux?

-- 
Felipe Contreras