Cairooverlay parallel with appsink produces abnormal CPU load

[Václav Mach]

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?

Best regards,

Vaclav

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Václav Mach]

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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel