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

[David Manpearl]

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?

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

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

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Justin Kim]

> On 20 Oct 2018, at 1:41 AM, David Manpearl <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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