Deadlock changing state PLAYING to PAUSE for multi source plugin

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Deadlock changing state PLAYING to PAUSE for multi source plugin

goussepi
Hi All,

I am writing a source plugin with one always video source pad and a sometime audio source pad.

To test it i made a pipeline where i connect my element to an xvimagesink and an alsasink using the pad-added signal for the later.

When i close the X window i exit the main loop and set the pipeline state to NULL.

In my element when going from PLAYING to PAUSE i call gst_pad_stop_task on each pad.

The application main thread is locked in the gst_pad_stop_task call on my element audio pad.
My element audio pad's task thread is locked in gst_pad_push.

The source code shows that gst_pad_push is waiting in GST_PAD_PREROLL_WAIT on the alsasink sink pad for either a PLAYING state or a flush.
gst_pad_stop_task is locked in GST_PAD_STREAM_LOCK logically as the stream lock is already acquired by my element audio pad's task function.

Is there something i should do in my element before calling gst_pad_stop_task ? Should i even call it there ? Any part of the documentation i have missed ?

Thanks for your help,

Pierre



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Deadlock changing state PLAYING to PAUSE for multi source plugin

Wim Taymans
On 06/04/2011 01:18 PM, pierre gousseau wrote:

> Hi All,
>
> I am writing a source plugin with one always video source pad and a
> sometime audio source pad.
>
> To test it i made a pipeline where i connect my element to an
> xvimagesink and an alsasink using the pad-added signal for the later.
>
> When i close the X window i exit the main loop and set the pipeline
> state to NULL.
>
> In my element when going from PLAYING to PAUSE i call gst_pad_stop_task
> on each pad.
>
> The application main thread is locked in the gst_pad_stop_task call on
> my element audio pad.
> My element audio pad's task thread is locked in gst_pad_push.
>
> The source code shows that gst_pad_push is waiting in
> GST_PAD_PREROLL_WAIT on the alsasink sink pad for either a PLAYING state
> or a flush.
> gst_pad_stop_task is locked in GST_PAD_STREAM_LOCK logically as the
> stream lock is already acquired by my element audio pad's task function.
>
> Is there something i should do in my element before calling
> gst_pad_stop_task ? Should i even call it there ? Any part of the
> documentation i have missed ?
>

You are not allowed to stop the task when going to the paused state
because the sink might still be busy in the chain function (blocking in
preroll).

Wim


> Thanks for your help,
>
> Pierre
>
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel