GNOME Bugzilla – Bug 602887
shout2send element won't change from PLAYING state to NULL
Last modified: 2009-11-28 20:38:35 UTC
Created attachment 148428 [details] Test case which demonstrates the problem. ... more precisely, the element will change to NULL, but only once the stream is complete. gst_element_set_state blocks until that point, waiting for a mutex. Attached is a test case which demonstrates the behavior. Provide an ogg vorbis file at least 30 seconds long; the program should end after only 15 seconds, but instead does not end until the audio file is complete. During this time, there are two threads (the pipeline thread and the control thread, I suppose.) The primary thread has a backtrace like this:
+ Trace 219274
The backtrace pretty printer ate my notes, which indicated that the second backtrace is an example of the playing thread. As the playing thread continues to run, it cannot be documented with a single backtrace.
We relied on scheduling to acquire a lock instead of explicitly giving up control of the streaming thread. Following patch fixes it. commit 4519bdc9833dc6d59135ef57873f45c273aee7b2 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Sat Nov 28 19:23:26 2009 +0100 shout2: use gstpoll for timeouts Use our own GstPoll based timeout instead of the shout sleep so that we can interrupt when doing a state change and shutting down. Fixes #602887
Thanks Wim.