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 671478 - Using autocluttersink in playbin2 leads to a deadlock when going from PAUSED to PLAYING
Using autocluttersink in playbin2 leads to a deadlock when going from PAUSED ...
Status: RESOLVED FIXED
Product: clutter-gst
Classification: Other
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: clutter-gst-maint
clutter-gst-maint
Depends on:
Blocks: 674083
 
 
Reported: 2012-03-06 15:53 UTC by Damien Lespiau
Modified: 2012-04-27 12:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Damien Lespiau 2012-03-06 15:53:39 UTC
When using autocluttersink in VideoTexture we seem to trigger quite often (~90%) a deadlock when going from PAUSED to PLAYING. It does not happen with cluttersink.

I can't pin anything wrong with autocluttersink itself, it sets up a ghostpad to cluttersink.

The state we end up with is the following:


So, from my limited understanding of gstreamer:

* Threads 6 and 7 are the sinks waiting for the preroll to be done
* Threads 3, 4 and 6 are waiting for a buffer to be consumed from a full queue
Comment 1 Damien Lespiau 2012-03-06 16:20:26 UTC
Some comments from the GStreamer overlords

16:51 < damien_l> Has anyone already seen a deadlock like the one I have in this bug? https://bugzilla.gnome.org/show_bug.cgi?id=671478
16:53 < wtay_> damien_l, doesn't look deadlocked to me, it looks like it's waiting in PAUSED
16:54 < damien_l> wtay_: right, except, it never stops waiting
16:54 < wtay_> damien_l, the wait_preroll methods mean that the sink is prerolled and now waiting for something to happen
16:55 < wtay_> damien_l, you need to set the element to PLAYING or READY/NULL for something to happen in this state
16:57 < damien_l> wtay_: hum, that's the result of trying to go to playing, if I have an element in a bin and the bin changes to 
                  PLAYING, do I have to set the elements inside the bin to PLAYING myself or is it done by GstBin?
16:57 < wtay_> damien_l, it is done by the bin
16:57 < __tim> unless you add the element dynamically
16:57 < __tim> (@damien_l)
16:58 < wtay_> damien_l, if it actually goes to playing depends on if the bin is toplevel or not
16:58 < wtay_> damien_l, if you have a bin with a sink and you set it to playing, it will stop at paused normally
16:59 < wtay_> damien_l, it relies on the parent of the bin to continue the state change to playing when  it prerolled
17:00 < damien_l> wtay_: right, in that case, it already went to playing once, then back to paused and this happens when going to 
                  playing another time
Comment 2 Damien Lespiau 2012-03-07 13:22:39 UTC
Spent a bit more time this morning on it, and indeed it's not deadlocking it's waiting in PAUSED state.

What happens is that playsink (one of the bins inside playbin2) thinks that the state change from PAUSED to PLAYING is going to happen asynchronously when autocluttersink is the video-sink and never receives any state update.

When using other sinks, including cluttersink, this does not happen (PAUSED -> PLAYING is synchronous).

I don't have much time to look at time right now, so I'm just going to revert the usage of autocluttersink in VideoTexture to cluttersink.
Comment 3 Damien Lespiau 2012-04-27 12:22:37 UTC
Pinged Josep Torra about this bug and he kindly took the time to fix it. Pushed the fix in master, will be part of 1.5.6