GStreamer hangs on gst_element_set_state() when trying to stop a transcode stream

Jeongseok Kim (Justin Joy Kim) justin.joy.9to5 at gmail.com
Mon Oct 22 02:26:30 UTC 2018



> On 20 Oct 2018, at 1:41 AM, David Manpearl <dmanpearl at gmail.com> wrote:
> 
> My call to stop RTP streaming with gst_element_set_state(GST_STATE_NULL) hangs when running the pipeline below. I want it to not hang.
> 
> I am using the pipeline below to stream to via RTP. When I try to stop via gst_element_set_state(GST_STATE_NULL) or gst_element_set_state(GST_STATE_READY), the gst_element_set_state() occasionally hangs (~10% of the time).
> 
> I have tried adding and removing various "queue" plugins, especially after the mux type plugins that may have multiple sink pads, but these have not significantly changed the issue. I have also tried without the audio portion of the pipeline with similar results.
> 
> I am starting the pipeline with gst_parse_launch(pipelineTxt) and gst_element_set_state(pipeline, GST_STATE_PLAYING);
> 
> I am using GStreamer 1.10.4 in Debian 9.4 within Docker. I cannot easily upgrade my version of GStreamer, but that would be a possibility if there is a known fix in a later version.
> 
> I have tried individually setting states through the cascade of legal transitions. The transition from GST_STATE_PLAYING to GST_STATE_PAUSED returns SUCCESS, but the transition from GST_STATE_PAUSED or GST_STATE_PLAYING to GST_STATE_READY often hangs (this is the issue).
> 
> Quetions
> 1. Is there anything wrong with my pipeline?

Not sure, but I guess your mpegtsmux received wrong PTS or DTS from time to time.
If it’s right, adding a parser behind encoder would be helpful to solve hanging problem.

> 2. Are there any suggestions for helping to resolve this issue?

You might be able to find which element is in race condition if you attach gdb to your running process.
I saw hanging pipeline when I did transmuxing so I wonder if it’s same situation with me.
Can you share the backtrace log?

> 3. When the hang occurs, is it possible to force it to stop and free resources without killing the app?

Maybe, solving deadlock is ideal solution, rather than detecting blocked status.

> 
> The Pipeline:
> filesrc name=gbxsrc location=video.MP4 ! qtdemux name=gbxdemux ! queue ! vaapih264dec ! vaapipostproc width=1280 height=720 ! videorate ! video/x-raw,framerate=30000/1001 ! vaapih264enc bitrate=3000 ! mpegtsmux name=mux ! rtpmp2tpay ! rtprtxqueue ! rtpbin.send_rtp_sink_0  rtpbin.send_rtp_src_0 ! udpsink name=gbxsink async=false port=5000 host=192.168.254.41  rtpbin name=rtpbin rtp-profile=avpf  gbxdemux. ! queue ! decodebin ! queue ! audioconvert ! audioresample ! avenc_aac ! mux.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



More information about the gstreamer-devel mailing list