Gstreamer on a Xeon cpu that has no integrated gpu

Hi, I’m trying to use gstreamer on a server that has a Xeon E-2336 Processor.

That processor has no integrated GPU and gstreamer is running terribly on it - just trying to autovideosink a 4k stream to screen sends the machine into overdrive (like showing 700% cpu usage on top) and I can’t get anywhere near 30 frames-per-sec. Lucky if I can get 10. And if I try to record to a webm file then the frame-rate drops even further to 1 or 2 fps. Plus I always get a lot of gstreamer errors on the console about dropping frames and buffers. This is all stuff that works fine on my other machine running intel core i5.

I guess this is expected on a chipset with no integrated graphics? I’m still a bit surprised it’s quite so bad though.

yes, not all Xeon’s have GPU’s and supports QuickSync.
For example:
we have “cutting” version Xeon E-2286M and it has GPU (630).
Also Xeon® E-2246G has GPU (P630).

In your case you can try

  1. add NVidia GPU and pushing encoding to it via “nvh264enc”
  2. or use mpeg-2 codec.

Thanks. I guess my guestion was - is it expected that gstreamer will run very poorly on those Xeon CPU’s without integrated graphics?

what is your pipe ?
If you use x264enc then you can try setup “speed-preset” to “ultrafast” (by default it’s “medium” ) or use “openh264enc” and setup param “usage-type” to “screen”.

GStreamer should work just fine using software codecs without hardware acceleration as well, especially on a beefy machine, but depending on the workload some CPU usage should be expected then of course.

GStreamer shouldn’t behave worse than any other multimedia framework in that scenario.

Performance might also depend on the specific plugins being used in your pipeline (e.g. openh264dec or libde265dec might perform much worse than, say, avdec_h264 or avdec_h265).

For autovideosink the specific sink being chosen might matter too.

We’d need to see more details about your pipeline and workloads to know if there are easy ways to make it less CPU intensive.

Thanks tpm. I’m mainly dealing in raw video and just use autovideosink for testing purposes to output to the screen. Here’s a few examples that I’ve been using to test:

gst-launch-1.0 decklinkvideosrc device-number=0 ! videoconvert ! autovideosink

gst-launch-1.0 decklinkvideosrc device-number=0 ! videoconvert ! vp8enc ! webmmux ! filesink location=output.webm

gst-launch-1.0 decklinkvideosrc device-number=0 ! videoconvert ! x264enc tune=zerolatency bitrate=800 ! rtspclientsink location=rtsp://localhost:8554/stream0

With videotestsrc I don’t see any overload or framerate issues, so I wonder if this is anything to do with the PCI interface for the decklinkvideosrc (a Blackmagic HDMI capture PCI card) on this machine.

Could you make some pipeline graph dumps, so we can see what caps are being negotiated ?

I’ve attached a graph dump of the machine that is not working well. I’ll attach one from the good machine in another graph.


graph from Dell - working well

With a bit more experimenting, I believe the issue may be on the output side. Maybe due to just having motherboard VGA graphics output on the Xeon server. The autovideosink window is much larger on that than on the Dell. If I restrict the size of the autovideosink window like so:

gst-launch-1.0 decklinkvideosrc device-number=0 ! videorate ! video/x-raw ! videoconvert ! videoscale ! video/x-raw,width=720,height=480 ! autovideosink

I find my CPU usage drops dramatically from 800% to 200%. Although still the video is not smooth and many frames are still being dropped. I can get something approaching smooth tv, and about 115% CPU usage, if I additional reduce the framerate to 10fps:

gst-launch-1.0 decklinkvideosrc device-number=0 ! videorate ! video/x-raw,framerate=10/1 ! videoconvert ! videoscale ! video/x-raw,width=720,height=480 ! autovideosink

Any chance you could also attach SVGs instead of JPGs - it’s not possible to read that long caps list on the source side (I’d like to check if that’s expected or if there’s some kind of mistake).