Cairooverlay parallel with appsink produces abnormal CPU load

Václav Mach mach.vasek at gmail.com
Thu Oct 18 08:35:28 UTC 2018


Actually, I'm rendering quite complex text descriptions using cairooverlay.
Thank you for your suggestions. For now, I have found another (less
effective) way how to solve my problem and I'll be looking forward for the
overlaycomposition element.

On Tue, Oct 16, 2018 at 1:58 PM Sebastian Dröge <sebastian at centricular.com>
wrote:

> On Tue, 2018-10-16 at 13:41 +0200, Václav Mach wrote:
> > Dear all,
> > I'm facing a problem with cairooverlay element. With the following
> > pipeline
> > rtspsrc ! rtph264depay ! decodebin ! imxg2dvideotransform ! tee
> > (first) ! queue (first) ! cairooverlay ! tee (second) ! queue
> > (second) ! imxg2dvideosink
> > everything works fine. When observing the CPU load in htop the thread
> > created by queue (first) has a CPU load of about 25% of one core.
> >
> > If I dynamically connect the following bin into tee (first)
> > queue (third) ! videorate ! capsfilter framerate=1/1 -> appsink
> > the CPU load of the thread created by queue (first) grows up to 60 %
> > and some video frames on output are missing the graphics created by
> > cairooverlay.
> >
> > Any advice how to avoid frames with missing cairo graphics and reduce
> > the CPU load, please?
>
> Depending on how/what you overlay, you could make use of the new
> overlaycomposition element (not merged yet):
>   https://bugzilla.gnome.org/show_bug.cgi?id=797234
>
> And then add support for the overlay composition meta to everything
> after your second tee (especially the sinks).
>
> cairooverlay is not going to be very fast generally.
>
>
> Why CPU usage in your specific case increases so much needs further
> debugging on your side. E.g. do the caps change when inserting that new
> pipeline branch? Does the cairooverlay now copy each frame before
> overlaying (because the new branch also has a reference to it)?
>
> My guess is the second, and the overlaycomposition element would
> prevent that.
>
> --
> Sebastian Dröge, Centricular Ltd · https://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181018/27d111da/attachment.html>


More information about the gstreamer-devel mailing list