gst_element_set_state deadlock
matschne
mathias.schneider at earthtv.com
Wed Apr 12 15:00:06 UTC 2017
Hey,
I think I've observed a deadlock in gst_element_set_state() when using the
appsink element, too. My application freezes in a random interval when I
want to change the state of a pipeline (from PLAYING to PAUSE or to NULL).
Depending on the input data, it happens once per week or every hour.
In my application, I have a bunch of "input" pipelines (filesrc, rtmpsrc,
rtspsrc) with a decodebin and a appsink:
i.e.
gst-launch-1.0 rtspsrc location=<URL> do-timestamp=true buffer-mode=2
protocols=0x00000004 latency=20000 ! rtph264depay ! h264parse ! decodebin
! videorate ! videoscale ! videoconvert ! watchdog timeout=120000 ! appsink
name=sink01 emit-signals=false async=false sync=true max-buffers=3 drop=true
And there is a "output" pipeline running (I know about the concat element
and the input-selector element but they do not fit my needs), feeded by a
thread. It is reading samples from appsink and push them to appsrc. Here is
what the code looks like:
GstSample* sample = NULL;
sample = gst_app_sink_try_pull_sample(GST_APP_SINK(source_sink),
TIME_MILLIS_TO_NANO(1000));
if (!sample) {
LOG("DEBUG: Smells like EOS or trouble");
} else {
buffer_sink = gst_sample_get_buffer (sample);
buffer_src = gst_buffer_copy (buffer_sink);
gst_sample_unref (sample);
ret = gst_app_src_push_buffer(my_appsrc, buffer_src);
if ( GST_FLOW_OK != ret) {
LOG("DEBUG: Could not send sample to my_appsrc");
}
}
After Sebastians hint I checked my source carefully - I definitely never
change the state of any pipeline outside of the GMainLoop. I ran my
application with GST_DEBUG=appsink:5 and GST_DEBUG_FILE=/tmp/appsink.txt.
Here is what it looks like for a "frozen" pipeline:
2:54:22.654784974 1 0x204d9e0 DEBUG appsink
gstappsink.c:769:dequeue_buffer:<source_sink02> dequeued buffer
0x7f15104e4070
2:54:22.654789009 1 0x204d9e0 DEBUG appsink
gstappsink.c:1458:gst_app_sink_try_pull_sample:<source_sink02> we have a
buffer 0x7f15104e4070
2:54:22.655399809 1 0x204d9e0 DEBUG appsink
gstappsink.c:1438:gst_app_sink_try_pull_sample:<source_sink02> trying to
grab a buffer
2:54:22.655407127 1 0x204d9e0 DEBUG appsink
gstappsink.c:1449:gst_app_sink_try_pull_sample:<source_sink02> waiting for a
buffer
2:54:22.694992808 1 0x7f139171dad0 DEBUG appsink
gstappsink.c:823:gst_app_sink_render:<source_sink02> pushing render buffer
0x7f156072bc90 on queue (0)
2:54:22.695030498 1 0x204d9e0 DEBUG appsink
gstappsink.c:1438:gst_app_sink_try_pull_sample:<source_sink02> trying to
grab a buffer
2:54:22.695036295 1 0x204d9e0 DEBUG appsink
gstappsink.c:769:dequeue_buffer:<source_sink02> dequeued buffer
0x7f156072bc90
2:54:22.695040547 1 0x204d9e0 DEBUG appsink
gstappsink.c:1458:gst_app_sink_try_pull_sample:<source_sink02> we have a
buffer 0x7f156072bc90
2:54:22.734320447 1 0x7f139171dad0 DEBUG appsink
gstappsink.c:823:gst_app_sink_render:<source_sink02> pushing render buffer
0x7f13b5b9b110 on queue (0)
2:54:22.734368013 1 0x7f139171dad0 DEBUG appsink
gstappsink.c:675:gst_app_sink_event:<source_sink02> receiving EOS
2:54:22.801331617 1 0x2053e30 DEBUG appsink
gstappsink.c:564:gst_app_sink_unlock_start:<source_sink02> unlock start
---> BAM! Deadlock!
Here is a example without a deadlock:
2:53:37.664156013 1 0x204dad0 DEBUG appsink
gstappsink.c:1438:gst_app_sink_try_pull_sample:<source_sink01> trying to
grab a buffer
2:53:37.664175322 1 0x204dad0 DEBUG appsink
gstappsink.c:769:dequeue_buffer:<source_sink01> dequeued buffer
0x7f154884fb20
2:53:37.664180376 1 0x204dad0 DEBUG appsink
gstappsink.c:1458:gst_app_sink_try_pull_sample:<source_sink01> we have a
buffer 0x7f154884fb20
2:53:37.665945471 1 0x204dad0 DEBUG appsink
gstappsink.c:1438:gst_app_sink_try_pull_sample:<source_sink01> trying to
grab a buffer
2:53:37.665975609 1 0x204dad0 DEBUG appsink
gstappsink.c:1449:gst_app_sink_try_pull_sample:<source_sink01> waiting for a
buffer
2:53:37.704112246 1 0x7f1544004370 DEBUG appsink
gstappsink.c:823:gst_app_sink_render:<source_sink01> pushing render buffer
0x7f1560792630 on queue (0)
2:53:37.704148439 1 0x7f1544004370 DEBUG appsink
gstappsink.c:675:gst_app_sink_event:<source_sink01> receiving EOS
2:53:37.704158813 1 0x204dad0 DEBUG appsink
gstappsink.c:1438:gst_app_sink_try_pull_sample:<source_sink01> trying to
grab a buffer
2:53:37.704171246 1 0x204dad0 DEBUG appsink
gstappsink.c:769:dequeue_buffer:<source_sink01> dequeued buffer
0x7f1560792630
2:53:37.704176664 1 0x204dad0 DEBUG appsink
gstappsink.c:1458:gst_app_sink_try_pull_sample:<source_sink01> we have a
buffer 0x7f1560792630
2:53:37.704809989 1 0x204dad0 DEBUG appsink
gstappsink.c:1438:gst_app_sink_try_pull_sample:<source_sink01> trying to
grab a buffer
2:53:37.704822144 1 0x204dad0 DEBUG appsink
gstappsink.c:1476:gst_app_sink_try_pull_sample:<source_sink01> we are EOS,
return NULL
2:53:37.705236465 1 0x2053e30 DEBUG appsink
gstappsink.c:564:gst_app_sink_unlock_start:<source_sink01> unlock start
2:53:37.705249499 1 0x2053e30 DEBUG appsink
gstappsink.c:579:gst_app_sink_unlock_stop:<source_sink01> unlock stop
Could there be a race condition in appsink? Or did I use the appsink /
appsrc in a forbidden way?
Mathias
tobatrance wrote
> Hi Sebastian.
>
> thanks for your reply and sorry for this visual noise. I can assure you
> that I'm calling the state change from the main thread. I did a workaround
> which creates another thread and sets the state to null from this thread.
> This is not very nice but solves the problem for so far.
tobatrance wrote
> Hi Sebastian.
>
> thanks for your reply and sorry for this visual noise. I can assure you
> that I'm calling the state change from the main thread. I did a workaround
> which creates another thread and sets the state to null from this thread.
> This is not very nice but solves the problem for so far.
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/gst-element-set-state-deadlock-tp4682492p4682639.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
More information about the gstreamer-devel
mailing list