GNOME Bugzilla – Bug 595513
Higher frame rates cause glimagesink to use excessive cpu
Last modified: 2010-04-30 10:08:04 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
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.
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.
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)