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 635532 - rtspsrc: unexpected eos when using authentication (regression)
rtspsrc: unexpected eos when using authentication (regression)
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal blocker
: 0.10.26
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-22 15:20 UTC by Nicola
Modified: 2010-11-30 00:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log that demostrate the 401 (32.29 KB, text/plain)
2010-11-29 14:31 UTC, Nicola
  Details
rtspsrc: handle stale digest authentication session data (5.14 KB, patch)
2010-11-29 14:39 UTC, Mark Nauwelaerts
committed Details | Review
rtsp: allow some slack in timeout interval (1.85 KB, patch)
2010-11-29 14:59 UTC, Mark Nauwelaerts
none Details | Review

Description Nicola 2010-11-22 15:20:29 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
Comment 1 Tim-Philipp Müller 2010-11-28 20:48:12 UTC
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.
Comment 2 Tim-Philipp Müller 2010-11-29 12:17:01 UTC
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).
Comment 3 Nicola 2010-11-29 13:05:47 UTC
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
Comment 4 Nicola 2010-11-29 14:31:32 UTC
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
Comment 5 Mark Nauwelaerts 2010-11-29 14:39:31 UTC
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).
Comment 6 Mark Nauwelaerts 2010-11-29 14:59:53 UTC
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.
Comment 7 Wim Taymans 2010-11-29 15:05:38 UTC
(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?
Comment 8 Mark Nauwelaerts 2010-11-29 15:22:12 UTC
> 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.
Comment 9 Tim-Philipp Müller 2010-11-30 00:57:11 UTC
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.