GNOME Bugzilla – Bug 635532
rtspsrc: unexpected eos when using authentication (regression)
Last modified: 2010-11-30 00:57:17 UTC
I'm using the following pipeline: gst-launch -m -v -t rtspsrc location=rtsp://a:a@192.168.2.136/axis-media/media.amp ! rtph264depay ! rtph264pay ! udpsink using the same camera it works fine with the latest stable release but systematically exit with an eos. I can reproduce this using the same pipeline connecting to the same camera, the old version (or vlc) works for hours the latest systematically exit, here are my versions: dpkg -l | grep gst ii gstreamer-tools 0.10.30.5-1~lucid1 Tools for use with GStreamer ii gstreamer0.10-ffmpeg 0.10.11-1~lucid1 FFmpeg plugin for GStreamer ii gstreamer0.10-plugins-bad 0.10.20-2~lucid3 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-base 0.10.30.5-2~lucid1 GStreamer plugins from the "base" set ii gstreamer0.10-plugins-good 0.10.25.5-1~lucid1 GStreamer plugins from the "good" set ii gstreamer0.10-tools 0.10.30.5-1~lucid1 Tools for use with GStreamer ii gstreamer0.10-x 0.10.30.5-2~lucid1 GStreamer plugins for X11 and Pango ii libgstreamer-plugins-base0.10-0 0.10.30.5-2~lucid1 GStreamer libraries from the "base" set ii libgstreamer0.10-0 0.10.30.5-1~lucid1 Core GStreamer libraries and elements ii python-gst0.10 0.10.19.4-1~lucid1 generic media-playing framework (Python bind the url is publicaly available: rtsp://a:a@62.123.237.212/axis-media/media.amp regards Nicola
I can reproduce the EOS behaviour. However, I get the same problem with core/base 0.10.30 and good 0.10.24. Maybe it's something that got fixed in 0.10.25 then? Can you try and narrow it down? Someone needs to investigate this urgently, or we'll just have to wait for the next release to fix it.
I have uploaded a log (using gstreamer core/base/good git + ugly/bad/ffmpeg releases): http://people.freedesktop.org/~tpm/635532.log.bz2 It seems the server closes the session and sends an EOS. I get the same behaviour with VLC 1.1.3. I also get the same behaviour with core/base git (0.10.30.5) and the last -good release (0.10.25). With core git (0.10.30.5) and last -base release (0.10.30) and the last -good release (0.10.25) it doesn't seem to time out (well, 10 minutes and going vs. the usual 2-3mins).
this seems an authentication problem in rtspsrc, running this pipeline: gst-launch -v -t -m --gst-debug=*RTSP*:5 rtspsrc debug=true location=rtsp://root:npgadmin@192.168.2.136/axis-media/media.amp ! fakesink I get this error: /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 180 bytes, timestamp: 0:02:49.850985462, duration: none, offset: -1, offset_end: -1, flags: 0) 0xced3880" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 129 bytes, timestamp: 0:02:49.884275680, duration: none, offset: -1, offset_end: -1, flags: 0) 0xced3770" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 146 bytes, timestamp: 0:02:49.917565887, duration: none, offset: -1, offset_end: -1, flags: 0) 0xced3660" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 98 bytes, timestamp: 0:02:49.950856084, duration: none, offset: -1, offset_end: -1, flags: 0) 0xcee63e0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 98 bytes, timestamp: 0:02:49.984135160, duration: none, offset: -1, offset_end: -1, flags: 0) 0xcee62d0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "event ******* E (type: 86, ) 0xcee0600" Got message #104 from element "pipeline0" (eos): no message details Got EOS from element "pipeline0". Execution ended after 169850696000 ns. Setting pipeline to PAUSED ... RTSP request message 0x7fffa7578450 request line: method: 'PAUSE' uri: 'rtsp://192.168.2.136/axis-media/media.amp' version: '1.0' headers: body: RTSP response message 0x7fffa7578410 status line: code: '401' reason: 'Unauthorized' version: '1.0' headers: key: 'CSeq', value: '9' key: 'Session', value: 'D534F418' key: 'WWW-Authenticate', value: 'Digest realm="AXIS_00408CA1207F", nonce="00091fb8Y786825cb4e7991b0ad8fd2ae341bdec4cca0c", stale=TRUE' key: 'WWW-Authenticate', value: 'Basic realm="AXIS_00408CA1207F"' key: 'Date', value: 'Mon, 29 Nov 2010 12:43:07 GMT' body: length 0 Setting pipeline to READY ... /GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0.GstGhostPad:recv_rtp_src_0_2519404503_96: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0.GstGhostPad:recv_rtp_src_0_2519404503_96: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0.GstGhostPad:send_rtcp_src_0: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0/GstRtpPtDemux:rtpptdemux0.GstPad:src_96: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink_rtcp: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_src_-1775562793: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_sink: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0/GstRtpSession:rtpsession0.GstPad:send_rtcp_src: caps = NULL /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0/GstRtpSession:rtpsession0.GstPad:sync_src: caps = NULL RTSP request message 0x7fffa7578450 request line: method: 'TEARDOWN' uri: 'rtsp://192.168.2.136/axis-media/media.amp' version: '1.0' headers: body: RTSP response message 0x7fffa7578410 status line: code: '454' reason: 'Session Not Found' version: '1.0' headers: key: 'CSeq', value: '10' key: 'Session', value: 'D534F418' key: 'Date', value: 'Mon, 29 Nov 2010 12:43:07 GMT' body: length 0 /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSink:udpsink1.GstPad:sink: caps = NULL Setting pipeline to NULL ... Freeing pipeline ... please note the 401 error, I cannot reproduce the issue using vlc 1.1.5 on windows
Created attachment 175467 [details] log that demostrate the 401 In the attacched log you can see a 401 error when rtspsrc send the third "GET PARAMETER" request (the error is sistematically reproducible), I noted the same thing with the 0.10.25 good release but with this release the pipeline ignore the error. Seeems that the periodic "GET PARAMETER" requests doesn't send authentication params the attached logs are generated with the following pipeline: gst-launch-0.10 -m -t --gst-debug=*rtspsrc*:5 rtspsrc debug=true location=rtsp://user:pass@<ip>/axis-media/media.amp ! fakesink
Created attachment 175468 [details] [review] rtspsrc: handle stale digest authentication session data Patch should handle the '401' (unauthorized) problem, which is not so much due to GET_PARAMETER not sending authorization stuff, but rather not updating it (when server-side indicates stale). FWIW, I doubt this being a regression, however, as that was never implemented so far. It may be due to server-side (= camera) changed configuration or so? Also, it does not seem to fix it completely, as server-side seems extremely picky about the timeout interval. That is, if it does not see some activity really within 60s, it gives up (and we may be missing that by some fraction) ( --> to be continued).
Created attachment 175470 [details] [review] rtsp: allow some slack in timeout interval As said earlier, this should prevent cutting it (too) close to send keep-alive (which should keep this stream going). Note: this is a -base patch.
(In reply to comment #6) > Created an attachment (id=175470) [details] [review] > rtsp: allow some slack in timeout interval > > As said earlier, this should prevent cutting it (too) close to send keep-alive > (which should keep this stream going). > > Note: this is a -base patch. Scaling of the timeout should already be done in the gst_rtsp_connection_next_timeout() method. Maybe it's not used here?
> Scaling of the timeout should already be done in the > gst_rtsp_connection_next_timeout() method. Maybe it's not used here? Indeed, my bad (git branch/update failure). Should already be taken care of in recent git -base.
This patch makes it work for me, thanks Mark! commit b6b0de0c49816c5acb5c9635b2fe8dd4d4dc5215 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Nov 29 15:32:40 2010 +0100 rtspsrc: handle stale digest authentication session data In particular, handle Unauthorized server response when trying to convey keep-alive. Fixes #635532.