Multiple sink usage in im6x
Nicolas Dufresne
nicolas at ndufresne.ca
Tue Jun 20 15:59:58 UTC 2017
Le mardi 20 juin 2017 à 13:21 +0900, Yasushi SHOJI a écrit :
> Hi,
>
> > On Thu, Jun 1, 2017 at 1:56 PM, Bhavya <bhavyar.1992 at gmail.com> wrote:
> >
> > Facing high CPU usage problem for 1080p video when used with multiple
> > display. Requirement is to have video playback in Front display and RSE
> > display.
> > Video sink need to be used is imxeglvivsink and imxv4l2sink.
> >
> > vpudec->tee --> queue -> imxeglvivsink
> > ---> queue ->imxv4l2sink
>
> 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).
I would suspect the imxeglvivsink can do zero copy in that case, as it
probably only rely on the VPU meta that sets the HW memory offset. I'm
assuming you have recent enough kernel, gstreamer-imx and gstreamer so
that works. For imxv4l2sink, I don't know much, if it's similar to
v4l2sink, your best bet would be to set something like io-mode=userptr
to try and avoid the copy (if implement and supported by the driver).
What is not currently possible, is for vpuedec to use downstream memory
through a tee element, so downstream renderer need to figure-out a way
to use the incoming memory without copying if you want this to be
performant enough.
regards,
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/20170620/330bf07a/attachment.sig>
More information about the gstreamer-devel
mailing list