Tee to forward allocation queries (was: Multiple sink usage in im6x)

[Nicolas Dufresne]

Le lundi 26 juin 2017 à 20:55 +0900, Yasushi SHOJI a écrit :
> Hi Nicolas,
> 
> On Wed, Jun 21, 2017 at 12:59 AM, Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
> > Le mardi 20 juin 2017 à 13:21 +0900, Yasushi SHOJI a écrit :
> > > the tee element reads FullHD buffer from vpudec to userland, memcpy() it, and
> > > enqueues/writes back to imxv4l2sink and imxeglvivsink.
> > >
> > > I don't know how those sinks are implemented but it takes some IO and CPU
> > > time for sure.
> >
> > With tee, the zero-copy options are indeed very limited as tee
> > currently drops the allocation queries. We don't know yet how to
> > aggregate an allocation query to enable some zero copy with a tee
> > (multiplexer).
> 
> It's off topic but what was the reason for tee to drop allocation queries?

To handle allocation queries, tee would need to aggregate them. Nobody
ever tried yet to aggregate an allocation query. I did thought about
it, but never had the time, and it was never required in any of my
projects.

> 
> GstBuffer has read-only shared capability, so it's possible to send the same buffer
> to multiple downstream?

Yes, but it's not related to allocation queries.

> 
> Even with dmabuf support, tee could forward allocation queries and resulting buffers
> back and forth, no?

You may have 1 branch that support GstVideMeta, and another that don't.
You need some aggregation logic so that the aggregated query won't
advertise GstVideoMeta and will drop any pool that relied on that. I
don't think we have all the require generic flags to handle that in an
agnostic way (remember, tee does not know about audio/video/text etc).
It's also possible that dropping all the pools and only doing upstream
allocation make sense for tee.

> 
> I'm not familiar with other device specific allocation method, but the GstBuffer,
> in theory, should encapsulate what's underneath right?

GstBuffer encapsulate one of more GstMemory, which may give you access
through map/unmap to the data. This is not the issue, the issue is that
depending on what is advertised in the allocation query, the memory
layout or the meta attached to that memory will differ. Not all GstMeta
can be ignored.

hope that helps,
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170626/a7ce5712/attachment.sig>