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 705912 - rtspsrc: server closes the connection but pipelines got stuck
rtspsrc: server closes the connection but pipelines got stuck
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-08-13 14:08 UTC by Guillaume Desmottes
Modified: 2018-11-03 14:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Guillaume Desmottes 2013-08-13 14:08:37 UTC
I have the following pipeline reading from a RTSP server:

gst-launch-1.0 rtspsrc location="..." protocols=0x00000004 ! decodebin name=demux ! queue ! videoconvert ! vp8enc ! webmmux name=mux ! filesink location=videos/webm/20121123-1_bb_pl.webm demux. ! queue ! audioconvert ! audioresample ! vorbisenc ! mux.

Most of the time it works fine and keep transcoding until the video is done. But sometimes for some reason (the server stopping to send?) the pipeline got stuck blocking my whole script. 

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Redistribute latency...
Redistribute latency...
WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
Additional debug info:
gstrtspsrc.c(3776): gst_rtspsrc_loop_interleaved (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
The server closed the connection.

Shouldn't the element raise an error and so the pipeline can be terminated?

gstreamer1.0-plugins-good:amd64       1.0.7-1~bpo70+1
Comment 1 Sebastian Dröge (slomo) 2013-08-14 08:44:15 UTC
Does it happen with every RTSP server? Every source (live or not?)? Does it only happen with TCP or also with UDP (unicast or multicast)? Which version of glib are you using, older versions had some bugs with child GSources.
Comment 2 Guillaume Desmottes 2013-08-14 09:39:02 UTC
Don't know I'm always transcoding from the same server. What do you mean by 'live'?
I'm only using TCP (see 'protocols=0x00000004').

libglib2.0-0:amd64                    2.33.12+really2.32.4-5 (Wheezy)
Comment 3 Sebastian Dröge (slomo) 2013-08-14 12:29:17 UTC
Is it a stream with infinite length or a known, fixed length? And can you try if it happens with UDP too, or is UDP not working for that stream?
Comment 4 Guillaume Desmottes 2013-08-19 08:12:56 UTC
Fixed length. Server only supports TCP so I can't test with UDP.
Comment 5 Wim Taymans 2013-10-04 04:58:40 UTC
This is detected as the server doing EOF on the file descripter. A warning is posted and EOS is pushed downstream. Maybe the problem is that the EOS gets stuck somewhere?
Comment 6 George Kiagiadakis 2018-05-06 14:32:04 UTC
Might be the same issue as 747801
Comment 7 GStreamer system administrator 2018-11-03 14:49:30 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/90.