Hello,
I have a synchr. callback handling the GST_MESSAGE_BUFFERING.
It sets the playbin2 to the state GST_STATE_PAUSED.
For that content, I see that the call chain blocks like this:
gst_element_set_state()
gst_element_set_state_func()
GST_STATE_LOCK(elm)
g_static_rec_mutex_lock()
Meanwhile, the test case stops the playback after 20 seconds.
For this, from the application context, the state is set to GST_STATE_NULL.
I see that that the call chain blocks like this:
gst_queue_src_active_push_pad(pad)
gst_pad_stop_task(pad)
GST_PAD_STREAM_LOCK(pad)
g_static_rec_mutex_lock()
I guess I hit a deadlock (nothing happens anymore).
I think about implementing a mutex in my code around a flag indicating
'locked for buffering state-change' or 'locked for stopping state-change'
to avoid the deadlock.
I guess such a deadlock might also occur when I try to "pause"
the progressive download stream.
Is this a good solution? Or is there a better gstreamer way?
PS
Immediately after the GST_PAD_STREAM_LOCK(pad),
I see the opposite GST_PAD_STREAM_UNLOCK(pad)
in gstpad.cc @ 5227
Might this be a left over in the code?
Or is this a check to verify a lock can be taken on the pad
before continuing doing the gst_task_join(GST_PAD_TASK(task))?
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
http://p.sf.net/sfu/bobj-july_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Locked
