After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 595513 - Higher frame rates cause glimagesink to use excessive cpu
Higher frame rates cause glimagesink to use excessive cpu
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-gl
0.10.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-09-17 20:53 UTC by Jae Stutzman
Modified: 2010-04-30 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jae Stutzman 2009-09-17 20:53:01 UTC
I'm not sure if this is something that can be fixed, but I noticed glimagesink using more cpu than I thought it should with my HD videos. I think it is related to the frame rate see the test launches below:

gst-launch-0.10 videotestsrc !  "video/x-raw-yuv, format=(fourcc)I420, width=1280, height=720, framerate=(fraction)80/1" ! fakesink sync=1

gst-launch-0.10 videotestsrc !  "video/x-raw-yuv, format=(fourcc)I420, width=1280, height=720, framerate=(fraction)80/1" ! glimagesink

gst-launch-0.10 gltestsrc ! "video/x-raw-gl, width=1280, height=720, framerate=(fraction)80/1" ! glimagesink

I know "top" is very relative, but these are my quick and dirty findings with my linux box:

fakesink uses: 15% CPU
glimagesink uses: 25% CPU

for reference:
gltestsrc uses: 2% CPU
Comment 1 Julien Isorce 2009-09-17 21:10:38 UTC
videotestsrc has to generate the video buffers using CPU. 
If you increase the framerate then CPU will work more to generate and fill in those buffers.
So the CPU% is increasing.

With gltestsrc the video textures are generated in hardware, that's why you got 2%.

So the main point is 15% vs 25%. Yes it should not have this difference.
I have an explanation:
When glimagesink receives a ram video buffer, it send it to the gl thread.
The gl thread is just a classic thread, and an opengl context is made current in there only one time.
To communicate to the glthread, in order to excute opengl code in there, there is an event loop which is running in the gl thread.
CPU is used to treat those events.

If you increase the framerate then there is more events.
More events they are, higher is the CPU.

I have the same behaviour on win32.

Well I am "working" (a long task) about reviewing this mecanism for a long time.
Having several opengl contexts shared together. And communicates to the glthread only for the final drawing. And avoind this communication for uploading and filtering.

But it's not for now. I have to understand better how gstreamer works before.
Because I have some locking points at the moment, that put my ideas to the trash.
Comment 2 Jae Stutzman 2009-09-17 21:53:18 UTC
Thanks for the explanation Julien.

I raised this issue to see if this was a limitation somewhere or possibly fixable. Based on your comment it seems fixable sometime in the future.
Comment 3 Julien Isorce 2010-04-30 10:08:04 UTC
Well, we forgot the following test to compare with:

gst-launch-0.10 videotestsrc !  "video/x-raw-yuv, format=(fourcc)I420,
width=1280, height=720, framerate=(fraction)80/1" ! xvimagesink

I do not see any noticeable CPU difference between this pipeline and the second one from the first comment. (xvimagesink/glimagesink)