appsrc performance issue

[Nicolas Dufresne]

Le mercredi 15 janvier 2020 à 12:39 -0600, mksafavi a écrit :
> Sorry for the late reply.
> 
> > Then you really want to proxy the allocation. The encoder requires
> > larger padding then what the decoder produce by default. 
> 
> I take a buffer from appsink and then wrap accelerator output into another
> buffer that I push it to appsrc.
> I think my decoder and encoder do not use the same buffer pool.
> 
> I think our design has another flaw. We cannot share buffers to the DMA from
> a userspace driver. to fix this issue without doing a copy we're going to
> setup SMMU (which works with VFIO driver) to initialize DMA with physical
> address but I'm not sure how it will perform.
> 
> > With Xilinx branch, it's fully handled already for what I'm aware, but for
> > that,
> > you need to proxy at least the allocation query. To do so, you have to
> > add a probe on the sink pad of that appsink, and then run that query on
> > the appsrc element. I believe that should be sufficient, but I never
> > tried on that board.
> 
> So, I should just get appsink query and then set it as appsrc's?
> 
> > Have you considered implementing a filter element instead ? 
> when I first started this project I wanted to implement a plugin. but the
> application way felt easier.
> If I fix current issues with appsrc, do they have performance differences?

The penalty of appsink/appsrc is mostly a queue and a thread. The rest
will depends on your application code.

> 
> > I wrote the other a quick minimal filter for that kind of use case, but
> > haven't
> > published it yet, it does not even have a build system yet. But maybe
> > it can be useful to you. Note that the buffer are not writable in this
> > example, comment out the code in my_minimal_init() if you need writable
> > init (and for that you need the latest release, since you need a gst-
> > omx without the NO_SHARE flags set on buffers)
> thanks. I'll be glad to check it.
> > https://gitlab.collabora.com/nicolas/minimal
> I think the repo is private, though.

Fixed, forgot to click "Save changes", oops.

> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel