GNOME Bugzilla – Bug 744420
splitmuxsink - Deadlock on while starting 2nd fragment on function gst_element_sync_state_with_parent
Last modified: 2015-08-28 18:27:44 UTC
Created attachment 296710 [details] Last logs before deadlock I tried to use new GStreamer element - splitmuxsink with RTSP streams bug meet problem with deadlock. My pipeline: GST_DEBUG=splitmuxsink:5 gst-launch-1.0 rtspsrc location=rtsp://192.168.2.5:8554/h264ESVideoTest ! rtph264depay ! h264parse ! splitmuxsink location=file%02d.mp4 max-size-time=10000000000 RTSP stream is slamtv60.ts stream from Live555 RTSP generator. I also tested with live webcam RTSP stream created with VLC and met the same problem. Vlc command which I used for generation live RTSP stream: cvlc v4l2:///dev/video0 --sout "#transcode{vcodec=h264,vb=0,scale=0,acodec=mp4a,ab=128,channels=2,samplerate=44100}:rtp{sdp='$RTSP_URL'}" & For above pipeline and both of the above stream first 10 second fragment is captured properly to file file00.mp4, but there is deadlock before capturing second fragment. I did quick investigation and found that deadlock happens in following function: gst_element_sync_state_with_parent (splitmux->active_sink); in file gstsplitmuxsink.c:675 Below I attach image of last visible logs from above pipeline before deadlock occured (notice that I added additional ERROR messages in order to find out where is deadlock): http://oi61.tinypic.com/nmntrp.jpg
Created attachment 296711 [details] Thread stacks while deadlock Attached thread stacks from gdb during deadlock.
Can't reproduce this here with a local RTSP stream, but it might well be racy. gst_element_sync_state_with_parent() is known to be a bit problematic, see bug #722767. I also don't see anything in splitmuxsink that intercepts GST_MESSAGE_ASYNC_START/DONE messages, which it should perhaps do so we don't mess with the state of the pipeline, the sink should act as a sink that does an async-start/done preroll at the beginning, but not for every file chunk IMHO. And maybe we should also flag the element as sink.
---------- Interesting observation -------------- This deadlock occurs only when I am dumping .dot files during processing. Please note difference between Pipeline1 and Pipeline2 below. -------------------------------------------- Pipeline1 - Deadlock occurs: -------------------------------------------- GST_DEBUG_DUMP_DOT_DIR=/tmp GST_DEBUG=splitmuxsink:4 gst-launch-1.0 videotestsrc ! x264enc ! h264parse ! splitmuxsink location=file%02d.mp4 max-size-time=3000000000 max-files=2 -------------------------------------------- Pipeline2 - Deadlock DOES NOT occur: -------------------------------------------- GST_DEBUG=splitmuxsink:4 gst-launch-1.0 videotestsrc ! x264enc ! h264parse ! splitmuxsink location=file%02d.mp4 max-size-time=3000000000 max-files=2 --------------------------------------------
Judging from your stack trace you seem to be testing this against gstreamer 1.4.4. Could you please try with git master instead (e.g. in an uninstalled setup)? Alternatively, could you provide the patch you use against 1.4.4 so we can test in the same setup. I can not reproduce the problem with your pipeline in git master, so it might either be a race, or it's been fixed already.
yes, you are right. I only reinstalled multifile module from the newest git modules. Other plugins are installed with version 1.4.4. I can be reason. If I will find some time I will test it fully with git master.
This fixes it for me, please reopen if not for you: commit b0ce43cde38e1a89f56c8e0a946a1fedc783656a Author: Jan Schmidt <jan@centricular.com> Date: Sat Mar 7 00:55:47 2015 +1100 splitmuxsink: Protect property variables with the object lock. Use the object lock instead of the splitmux lock to protect internal property variables, so they're not locked when switching to a new file. https://bugzilla.gnome.org/show_bug.cgi?id=744420