[Bug 726325] RFC: Add tunneling support.

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #28 from deathsimple at vodafone.de <deathsimple at vodafone.de> 2014-03-19 13:50:00 UTC ---
(In reply to comment #21)
> Review of attachment 271863 [details]:
> 
> ::: omx/gstomxvideoenc.c
> @@ +1665,2 @@
>    gst_query_add_allocation_meta (query, GST_VIDEO_META_API_TYPE, NULL);
> 
> 
> 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.

> 
> @@ +1683,3 @@
> +
> +    gst_query_add_allocation_pool (query, pool, GST_VIDEO_INFO_SIZE (&info),
> 0,
> +      return FALSE;
> 
> should unref the pool

fixed.

> 
> @@ +1688,3 @@
>    return
>        GST_VIDEO_ENCODER_CLASS
>        (gst_omx_video_enc_parent_class)->propose_allocation (encoder, query);
> 
> I think in the best gst-omx tunneling support it would not need to have a
> buffer pool at all between tunneled gstomx elements. (note that here the pool
> has min=max=0 size I guess it is only here to share the peer port)

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.

> If you manage to get ride of those task/loop (see other reviews), then
> gst_video_decoder_allocate_output_buffer (underlying call acquire on the buffer
> pool) and gst_omx_port_acquire_buffer would not be called on corresponding
> tunneled ports.
> 
> 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.

-- 
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.