[Bug 726325] RFC: Add tunneling support.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=726325
  GStreamer | gst-omx | git

Nicolas Dufresne <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #30 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-03-19 14:47:35 UTC ---
(In reply to comment #28) 
> > If tunneled, I think do not add GST_VIDEO_META_API_TYPE
> 
> Actually I'm not sure why we need to add that in the first place.
> 

the VIDEO meta is need if your element is producing data with special stride or
with special padding (hence offset). Otherwise it would not be possible to map
the video buffer. If you are not producing videobuffers, you don't care much.
Though if the last element in a chain of tunneled omx component is not a sink,
this element will have to care.

> Disagree. Actually I think that it would be best to move most of the buffer
> allocation / deallocation handling into the buffer pool instead and in the case
> of tunneling setup and teardown of that as well.

Long story short, to do things correctly, we also need an allocator and
possibly a memory implementation. But this is not your fault.

> > I think the proper way to share the peer omx port would be to define a new
> > allocation meta: GST_OMX_TUNNELING_META_API_TYPE and do the following in the
> > propose_allocation side:
> > 
> > s = gst_structure_new ("GstOMXTunnelingMeta", "peer", GST_OMX_PORT_TYPE,
> > self->in_port, NULL);
> > gst_query_add_allocation_meta (query, GST_OMX_TUNNELING_META_API_TYPE, s);
> > 
> > Then in decide_allocation checks the presence of
> > GST_OMX_TUNNELING_META_API_TYPE, if yes then retrieve the peer port.
> 
> That actually sounds extremely odd to me, cause openmax tunneling parameters
> aren't metadata that could apply to any type of buffer.

We are not talking about buffer here, but about allocation, like in allocation
query. These are meta informat that you can set to help upstream make a
decision about how allocation will be handled, or to figure-out if you need
allocation at all. Obviously this is aiming other OMX component, not any kind
of element. Also, it would remain private to the gst-omx. I think it's a
promising approach, that is worth looking into.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.