Cairooverlay parallel with appsink produces abnormal CPU load

[Sebastian Dröge]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181016/382638a3/attachment.sig>