GNOME Bugzilla – Bug 721425
uridecodebin isn't always able to stream from gst-rtsp-server
Last modified: 2018-05-05 16:15:46 UTC
When using uridecodebin to stream from gst-rtsp-server there seems to be some kind of race condition that makes it so sometimes it will play fine and sometimes block just after starting. Here's a simple way to test this: 1) Run test-video from the gst-rtsp-server examples 2) Launch the following pipeline: gst-launch-1.0 uridecodebin uri=rtsp://127.0.0.1:8554/test ! videoconvert ! ximagesink Most of the time this will result in a stopped pipeline. Sometimes though it will play fine. Timing seems to be key as changing debug level alters the frequency of the problem ocurring. Here's the GST_DEBUG=4 output of one of the times it stopped: 0:00:00.852989096 4100 0xb6536f50 INFO GST_STATES gstelement.c:2328:gst_element_continue_state:<source> completed state change to PLAYING 0:00:00.853116914 4100 0xb6536f50 INFO GST_STATES gstbin.c:2656:gst_bin_change_state_func:<uridecodebin0> child 'source' changed state to 4(PLAYING) successfully 0:00:00.853237256 4100 0xb6536f50 INFO GST_STATES gstelement.c:2328:gst_element_continue_state:<uridecodebin0> completed state change to PLAYING 0:00:00.853350332 4100 0xb6536f50 INFO GST_STATES gstelement.c:2233:_priv_gst_element_state_changed:<uridecodebin0> notifying about state-changed PAUSED to PLAYING (VOID_PENDING pending) 0:00:00.853610213 4100 0xb6536f50 INFO GST_STATES gstbin.c:2656:gst_bin_change_state_func:<pipeline0> child 'uridecodebin0' changed state to 4(PLAYING) successfully 0:00:00.853897732 4100 0xb6536f50 INFO GST_STATES gstelement.c:2328:gst_element_continue_state:<pipeline0> completed state change to PLAYING 0:00:00.853972143 4100 0xb6536f50 INFO GST_STATES gstelement.c:2233:_priv_gst_element_state_changed:<pipeline0> notifying about state-changed PAUSED to PLAYING (VOID_PENDING pending) 0:00:01.538434967 4100 0xb5b01e90 INFO GST_EVENT gstevent.c:709:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 0:00:01.538596623 4100 0xb5b01e90 INFO basesrc gstbasesrc.c:2778:gst_base_src_loop:<udpsrc4> marking pending DISCONT 0:00:01.538852051 4100 0xb5b01e90 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp, ssrc=(uint)2111828647 0:00:01.538969446 4100 0xb5b01e90 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp 0:00:01.539035799 4100 0xb5b01e90 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp, ssrc=(uint)2111828647 0:00:01.700806657 4100 0xb652ee00 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp 0:00:01.701917220 4100 0xb652ee00 INFO GST_EVENT gstevent.c:709:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 0:00:01.788936625 4100 0xb650f830 INFO GST_EVENT gstevent.c:709:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 0:00:01.789113468 4100 0xb650f830 INFO basesrc gstbasesrc.c:2778:gst_base_src_loop:<udpsrc1> marking pending DISCONT 0:00:01.789374905 4100 0xb650f830 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp, ssrc=(uint)3846578192 0:00:01.789613075 4100 0xb650f830 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp 0:00:01.789796425 4100 0xb650f830 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp, ssrc=(uint)3846578192 0:00:02.123445837 4100 0xb652ee30 INFO GST_EVENT gstevent.c:628:gst_event_new_caps: creating caps event application/x-rtcp 0:00:02.123588691 4100 0xb652ee30 INFO GST_EVENT gstevent.c:709:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 0:00:02.431870032 4100 0xb510d120 INFO rtpjitterbuffer gstrtpjitterbuffer.c:2723:do_deadline_timeout:<rtpjitterbuffer0> got deadline timeout
This sounds familiar, I think I had similar problems with gst-launch and using rtspsrc directly sometimes. And this indeed also shows the same behaviour: > gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/test ! decodebin ! videoconvert ! ximagesink For me it's in about 25% of the cases that it stops. I think with my previous testing some time ago this also behaved different depending on whether buffering is used (non-live case with known duration) or not.
This is definitely something to do with buffering. If you let the pipeline sit for a while eventually you get a bunch of messages about packets that have arrived too late and have been discarded. A wild guess is that rtpjitterbuffer has some logic error that makes it block the pipeline.
Any idea how to fix this? My app hits this bug 90% of the time, making it pretty annoying to test.
Does not seem to happen for me. Is this with git?
Just tested against git master and got the same result as before.
gst-launch-1.0 uridecodebin uri=rtsp://127.0.0.1:8554/test ! decodebin ! videoconvert ! xvimagesink is working fine on my environment
Closing after 4 years of inactivity. If you can reproduce with uridecodebin3 on latest GStreamer, please re-open.