After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744420 - splitmuxsink - Deadlock on while starting 2nd fragment on function gst_element_sync_state_with_parent
splitmuxsink - Deadlock on while starting 2nd fragment on function gst_elemen...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal major
: 1.5.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-12 19:14 UTC by Damian Ziobro
Modified: 2015-08-28 18:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Last logs before deadlock (470.65 KB, image/png)
2015-02-12 19:14 UTC, Damian Ziobro
Details
Thread stacks while deadlock (21.99 KB, text/plain)
2015-02-12 19:25 UTC, Damian Ziobro
Details

Description Damian Ziobro 2015-02-12 19:14:06 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
Comment 1 Damian Ziobro 2015-02-12 19:25:39 UTC
Created attachment 296711 [details]
Thread stacks while deadlock

Attached thread stacks from gdb during deadlock.
Comment 2 Tim-Philipp Müller 2015-02-13 20:30:19 UTC
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.
Comment 3 Damian Ziobro 2015-02-20 14:44:42 UTC
---------- 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

--------------------------------------------
Comment 4 Tim-Philipp Müller 2015-02-20 16:02:32 UTC
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.
Comment 5 Damian Ziobro 2015-02-20 16:15:55 UTC
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.
Comment 6 Jan Schmidt 2015-03-06 14:04:11 UTC
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