GNOME Bugzilla – Bug 537832
rtsp is broken
Last modified: 2009-06-15 20:22:48 UTC
we now test 6 different ip camera which support rtsp with similar command line: gst-launch playbin uri=rtsp://192.168.2.90/live.sdp unfortunately only one working with all other crash with different errors. the biggest problem is that's not the cameras fault or at least all camera's rtsp works with vlc and mplayer. so only gstreamer fails:-( gst-launch rtspsrc debug=1 location=rtsp://192.168.2.90/live.sdp ! decodebin ! queue ! xvimagesink &>good.txt gst-launch rtspsrc debug=1 location=rtsp://192.168.2.100/live.sdp ! decodebin ! queue ! xvimagesink &>bad.txt gst-launch rtspsrc debug=1 location=rtsp://admin:admin@192.168.2.109/ ! decodebin ! queue ! xvimagesink &>ugly.txt anc ctrl-c to stop. the good working the last two case (bad, ugly), there was not any xv window at all so we just hit ctrl-c after about 1 minutes. all of the above url working with vlc and mplayer from the same host.
Created attachment 112563 [details] the good
Created attachment 112564 [details] the bad
Created attachment 112565 [details] the ugly
It seems to be related to how the multicast connection is supposed to be set up for those last 2 cameras.
Can you make a log like this for the third camera: GST_DEBUG=*rtspsrc*:5 gst-launch ... >debug.log 2>&1 gzip and attach it here?
Created attachment 112609 [details] the logfile anyway this camera is a Linksys PVC2300
It seems the udpsrc cannot allocate the socket for some reason. Can you make a new log with more debug info like this: GST_DEBUG=*rtspsrc*:5,*udp*:5 gst-launch ... >debug.log 2>&1
Created attachment 112617 [details] the 2nd log
Thanks, it turned out the udp sources did not make it to PAUSED so they didn't join the multicast group. I could not test it but this should fix it: * gst/rtsp/gstrtspsrc.c: (gst_rtspsrc_stream_configure_mcast): Set udpsrc for receiving data from multicast groups to PAUSED instead of leaving them in READY. Fixes #537832.
which version will include this fix? or how can i test it? eg. is there a patch with which i can recompile fedora packages?
hi, we retest rtsp with the latest gstreamer-plugins-good-0.10.9 and still broken. here are a more detaild description why compared vlc with gstreamer (since vlc is working): 1. Wrong initiation: GStreamer session (+: GSrtreamer -: Camera) +OPTIONS rtsp://192.168.150.200/live.sdp RTSP/1.0 +CSeq: 0 +Date: Fri, 22 Aug 2008 10:55:28 GMT -RTSP/1.0 200 OK -CSeq: 0 -Date: Fri, 22 Aug 2008 12:55:31 GMT -Public: OPTIONS, DESCRIBE, PLAY, SETUP, TEARDOWN +DESCRIBE rtsp://192.168.150.200/live.sdp RTSP/1.0 +CSeq: 1 +Accept: application/sdp +Date: Fri, 22 Aug 2008 10:55:28 GMT -RTSP/1.0 200 OK -CSeq: 1 -Date: Fri, 22 Aug 2008 12:55:31 GMT -Content-Base: rtsp://192.168.150.200/live.sdp/ -Content-Type: application/sdp -Content-Length: 343 - -v=0 -o=RTSP 1219409731 337 IN IP4 0.0.0.0 -s=RTSP server -c=IN IP4 0.0.0.0 -t=0 0 -a=charset:Shift_JIS -a=range:npt=0- -a=control:* -a=etag:1234567890 -m=video 0 RTP/AVP 96 -b=AS:0 -a=rtpmap:96 MP4V-ES/30000 -a=control:trackID=1 -a=fmtp:96 -profile-level-id=3;config=000001B003000001B509000001000000012000C48881F4514043C1463F;decode_buf=76800 +SETUP rtsp://192.168.150.200/live.sdp/trackID=1 RTSP/1.0 +CSeq: 2 +Transport: +RTP/AVP/UDP;unicast;client_port=39498-39499,RTP/AVP/UDP;multicast,RTP/AVP/TCP;unicast;interleaved=0-1 +Date: Fri, 22 Aug 2008 10:55:28 GMT -RTSP/1.0 503 Service Unavailable -CSeq: 2 VLC session ( +:VLC, - :Camera) ----------------------------- +OPTIONS rtsp://192.168.150.200/live.sdp RTSP/1.0 +CSeq: 1 +User-Agent: VLC media player (LIVE555 Streaming Media v2008.04.02) -RTSP/1.0 200 OK -CSeq: 1 -Date: Tue, 19 Aug 2008 16:42:30 GMT -Public: OPTIONS, DESCRIBE, PLAY, SETUP, TEARDOWN +DESCRIBE rtsp://192.168.150.200/live.sdp RTSP/1.0 +CSeq: 2 +Accept: application/sdp +User-Agent: VLC media player (LIVE555 Streaming Media v2008.04.02) -RTSP/1.0 200 OK -CSeq: 2 -Date: Tue, 19 Aug 2008 16:42:30 GMT -Content-Base: rtsp://192.168.150.200/live.sdp/ -Content-Type: application/sdp -Content-Length: 343 - -v=0 -o=RTSP 1219164150 610 IN IP4 0.0.0.0 -s=RTSP server -c=IN IP4 0.0.0.0 -t=0 0 -a=charset:Shift_JIS -a=range:npt=0- -a=control:* -a=etag:1234567890 -m=video 0 RTP/AVP 96 -b=AS:0 -a=rtpmap:96 MP4V-ES/30000 -a=control:trackID=1 -a=fmtp:96 -profile-level-id=3;config=000001B003000001B509000001000000012000C48881F4514043C1463F;decode_buf=76800 +SETUP rtsp://192.168.150.200/live.sdp/trackID=1 RTSP/1.0 +CSeq: 3 +Transport: RTP/AVP;unicast;client_port=36774-36775 +User-Agent: VLC media player (LIVE555 Streaming Media v2008.04.02) -RTSP/1.0 200 OK -CSeq: 3 -Date: Tue, 19 Aug 2008 16:42:30 GMT -Session: 2579728;timeout=80 -Server: PVSS -Transport: RTP/AVP;unicast;client_port=36774-36775;server_port=5556-5557 +PLAY rtsp://192.168.150.200/live.sdp/ RTSP/1.0 +CSeq: 4 +Session: 2579728 +Range: npt=0.000- +User-Agent: VLC media player (LIVE555 Streaming Media v2008.04.02) -RTSP/1.0 200 OK -CSeq: 4 -Date: Tue, 19 Aug 2008 16:42:30 GMT -Session: 2579728;timeout=80 -Server: PVSS -RTP-Info: url=rtsp://192.168.150.200/live.sdp/trackID=1;seq=0;rtptime=0 -Range: npt=0- -RTCP-Interval: 250 +TEARDOWN rtsp://192.168.150.200/live.sdp/ RTSP/1.0 +CSeq: 5 +Session: 2579728 +User-Agent: VLC media player (LIVE555 Streaming Media v2008.04.02) -RTSP/1.0 200 OK -CSeq: 5 -Session: 2579728 The camera type is Vivotek IP7138. I think the main difference is that the VLC client doesn't use the interleaved parameter in the SETUP command ---------------------------------------------------------------------------- 2. Missing TEARDOWN when the program is closed. Only a PAUSE is sent. On some cameras this prevents the start of the next session for a while.
Yeah, we send all possible protocols we can accept with the first SETUP request. The server is supposed to select one protocol. This is completely according to the RTSP specs but it seems too many servers don't handle this correctly. It needs some fixing...
and imho the missing teardown (problem 2.) cause most of our problems!
Can you describe exactly what goes wrong and what you think should happen instead in the case of the teardown? AFAIK the RFC says you should do a TEARDOWN after a successfull SETUP.
in #11 i describe 2 different problem (i should have to open another ticket?). 1. the first is the interleaved parameter in the SETUP (which differs from vlc). 2. when i run gst-launch... and stop it with ctrl-c then gstreamer do _not_ send teardown which not cause problem in the client side, but may cause problems in the server side. and gstreamer only pause (not even stop) the pipeline and not send teardown. which is imho a bug in gstreamer.
any progress which the two rtsp bug?
I made so that it only sends 1 transport string at a time. * gst/rtsp/gstrtspsrc.c: (gst_rtspsrc_create_transports_string), (gst_rtspsrc_change_state): Only send one transport at a time for improved compatibility with some broken servers. See #537832.
which version will include this fix? or it's already in a released version?
next version of gst-plugins-good, version 0.10.12 to be released somewhere next year.
-good comes after core/base, Wim - which makes it January :)
January came and went. Can we presume this is fixed?
There's been a (several, actually) new release of the gst-plugins-good module that included Wim's commit: http://gstreamer.freedesktop.org/releases/gst-plugins-good/0.10.14.html
Levente, could you confirm this issue is fixed ?
Let's close this as FIXED. Lots of RTSP progress in the last few months in various modules. I'm sure there are still RTSP issues, but please just file new bugs about them - one per URI preferably, thanks!