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 625023 - rtspsrc inconsistent behaviour
rtspsrc inconsistent behaviour
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.23
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-22 10:21 UTC by Marc Leeman
Modified: 2010-07-23 11:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Marc Leeman 2010-07-22 10:21:47 UTC 
We have an encoder that is streaming perfectly and as expected when using RTSP (defaults to unicast).

However; when specifically requesting a multicast address from the encoder; the encoder replies to RTCP requests with 

RTSP request message 0x44732e40
 request line:
   method: 'GET_PARAMETER'
   uri: 'rtsp://10.3.0.173/axis-media/media.amp?latency=50&videocodec=h264&debug=1&protocols=2'
   version: '1.0'
 headers:
 body:
RTSP response message 0x44732f60
 status line:
   code: '454'
   reason: 'Session Not Found'
   version: '1.0'
 headers:
   key: 'CSeq', value: '9'
   key: 'Session', value: '936FAA71'
   key: 'Date', value: 'Thu, 16 Aug 2001 11:22:41 GMT'
 body: length 0 

even though that the encoder keeps on happily sending the stream (and keeps it alive). However, the rtspsrc does no longer accept/listen to the stream.


With unicast the reply from the encoder is
RTSP request message 0x44771e40
 request line:
   method: 'GET_PARAMETER'
   uri: 'rtsp://10.3.0.173/axis-media/media.amp?latency=50&videocodec=h264&debug=1&protocols=1'
   version: '1.0'
 headers:
 body:
RTSP response message 0x44771f60
 status line:
   code: '200'
   reason: 'OK'
   version: '1.0'
 headers:
   key: 'CSeq', value: '5'
   key: 'Session', value: '31EFAC72'
   key: 'Date', value: 'Thu, 16 Aug 2001 11:25:27 GMT'
 body: length 0 

Even though that the encoder gives the wrong reply; rtspsrc keeps on sending RTCP requests; while not listening to the data anymore.

If rtspsrc decides to discontinue listening to the data; should it not simply stop sending the rtcp packages too; so the pipeline exits (and can cleanly be restarted).
Comment 1 Marc Leeman 2010-07-22 16:17:57 UTC 
RTSP request message 0x43cfdde0
 request line:
   method: 'GET_PARAMETER'
   uri:    'rtsp://10.3.0.173/axis-media/media.amp?latency=50&videocodec=h264&debug=1&encoding-name=H264&protocols=2'
   version: '1.0'
 headers:
 body:
RTSP response message 0x43cfde90
 status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
 headers:
   key: 'CSeq', value: '5'
   key: 'Session', value: '82062575'
   key: 'Date', value: 'Thu, 23 Aug 2001 11:25:20 GMT'
 body: length 0
RTSP request message 0x43cfdde0
 request line:
   method: 'GET_PARAMETER'
   uri:    'rtsp://10.3.0.173/axis-media/media.amp?latency=50&videocodec=h264&debug=1&encoding-name=H264&protocols=2'
   version: '1.0'
 headers:
 body:
RTSP response message 0x43cfde90
 status line:
   code:   '454'
   reason: 'Session Not Found'
   version: '1.0'
 headers:
   key: 'CSeq', value: '6'
   key: 'Session', value: '82062575'
   key: 'Date', value: 'Thu, 23 Aug 2001 11:26:20 GMT'
 body: length 0

** (gst-launch-0.10:31355): WARNING **: unknown SSRC 034f6bb6
RTSP request message 0x43cfdde0
 request line:
   method: 'GET_PARAMETER'
   uri:    'rtsp://10.3.0.173/axis-media/media.amp?latency=50&videocodec=h264&debug=1&encoding-name=H264&protocols=2'
   version: '1.0'
 headers:
 body:
RTSP response message 0x43cfde90
 status line:
   code:   '454'
   reason: 'Session Not Found'
   version: '1.0'
 headers:
   key: 'CSeq', value: '7'
   key: 'Session', value: '82062575'
   key: 'Date', value: 'Thu, 23 Aug 2001 11:27:20 GMT'
 body: length 0
Comment 2 Marc Leeman 2010-07-23 11:28:05 UTC 
Even thought the Axis encoder seems to act up; the failure to stop the pipeline was due to the application; and the TEARDOWN happening before the bus was monitored.