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 728759 - glimagesink: Won't display anything on high loads
glimagesink: Won't display anything on high loads
Status: RESOLVED DUPLICATE of bug 729335
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-22 22:11 UTC by Nicolas Dufresne (ndufresne)
Modified: 2014-05-01 15:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicolas Dufresne (ndufresne) 2014-04-22 22:11:57 UTC 
In the context where the display is slower then the stream, glimagesink won't display anything. eglglessink was behaving much better. Maybe something in QoS is missing, I don't know yet.
Comment 1 Sebastian Dröge (slomo) 2014-04-23 07:16:12 UTC 
basesink is doing all the QoS work already, and if everything is just too slow it will try to display one frame per second at least.
Comment 2 Nicolas Dufresne (ndufresne) 2014-04-23 12:31:03 UTC 
I've been digging a bit more, it seems this is yet another deadlock actually. I will provide a backtrace. Do we have any docs/design about the messaging and threading of the libgstgl ?
Comment 3 Sebastian Dröge (slomo) 2014-04-23 12:52:06 UTC 
We don't unfortunately, but maybe someone already knows the problem if you can provide the backtrace of the deadlock :)
Comment 4 Nicolas Dufresne (ndufresne) 2014-04-27 14:06:44 UTC 
I notice that moving prepare inside _render makes the situation much nicer. Looking deeper, basesink does:

- if late skip
- prepare
- sync
- if late skip
- render

In the current situation, display is really slow, 10fps, which means prepare takes probably more then a frame to run (I need to measure this). I'm not fully clear yet, but it seems like this pattern cause starvation. Note the basetransform QoS is also involved here. We could also experiment by adding sleeps in these.
Comment 5 Nicolas Dufresne (ndufresne) 2014-05-01 15:23:25 UTC 
Had nothing to do with gl in fact.

*** This bug has been marked as a duplicate of bug 729335 ***