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 752702 - rtspsrc: Does not expose UDP streams of unknown media type
rtspsrc: Does not expose UDP streams of unknown media type
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.5.2
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-22 09:33 UTC by ianw21
Modified: 2018-05-06 11:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description ianw21 2015-07-22 09:33:25 UTC
Hi,

The sdp plugin doesn't seems to be able to handle the media proto of udp

gst-launch-1.0 rtsp://192.168.0.216/test
Progress: (open) Retrieving media info
0:00:00.293490541  3031  0x8356800 ERROR                rtspsrc gstrtspsrc.c:1528:gst_rtspsrc_collect_payloads:<rtspsrc0> unknown proto in media udp
0:00:00.295366796  3031  0x8356800 ERROR                rtspsrc gstrtspsrc.c:7069:gst_rtspsrc_open_from_sdp:<rtspsrc0> setup failed
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: No supported stream was found. You might need to allow more transport protocols or may otherwise be missing the right GStreamer RTSP extension plugin.
Additional debug info:
gstrtspsrc.c(6818): gst_rtspsrc_setup_streams (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0

The sdp description is this:

RTSP/1.0 200 OK
Content-Length: 249
CSeq: 2
Date: Wed, Jul 22 2015 09:14:36 GMT
Content-Type: application/sdp

v=0
o=- 15661792707495986318 15661792707495986318 IN IP4 192.168.0.216
c=IN IP4 192.168.0.216
t=0 0
a=range:npt=0-600.064
a=control:rtsp://192.168.0.216/test
b=AS:4542
m=video 0 udp 33

Is there any other module I need to include for this or does the gstreamer simply not support the udp proto ?

Thanks.
Ian.
Comment 1 Tim-Philipp Müller 2015-07-22 10:05:51 UTC
It supports RTP-over-UDP, which would be something like this (IIRC):

m=video 123 RTP/AVP 456
Comment 2 ianw21 2015-07-22 13:09:22 UTC
Ok. Unfortunately my media server sends udp (which according to rfc4566 denotes an unspecified protocol running over UDP). vlc, mplayer and xbmc all play the stream ok. I was hoping to use gstreamer but I guess I need to look at the media server to see if I can change it to specify rtp/avp instead of udp.
Thanks.
Comment 3 Nicolas Dufresne (ndufresne) 2015-07-22 15:00:59 UTC
(In reply to ianw21 from comment #2)
> Ok. Unfortunately my media server sends udp (which according to rfc4566
> denotes an unspecified protocol running over UDP). vlc, mplayer and xbmc all
> play the stream ok. I was hoping to use gstreamer but I guess I need to look
> at the media server to see if I can change it to specify rtp/avp instead of
> udp.
> Thanks.

As the format is unspecified, I don't know how any player manage to play it. If you can find more information, we can probably help you.
Comment 4 ianw21 2015-07-23 08:26:03 UTC
Hi,
I changed the media server format to RTP/AVP rather than udp and gstreamer now plays the stream ok.

FYI this is the wireshark trace for vlc when the media format is udp:

----------------------------------------------

OPTIONS rtsp://192.168.0.216/test RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.1.6 (LIVE555 Streaming Media v2014.01.13)

RTSP/1.0 200 OK
Content-Length: 0
CSeq: 2
Server: Packet Ship RTSP Server v3.1.8
Date: Thu, Jul 23 2015 07:32:45 GMT
Public: GET_PARAMETER, SET_PARAMETER, PLAY, PAUSE, DESCRIBE, OPTIONS,
 SETUP, TEARDOWN
--
DESCRIBE rtsp://192.168.0.216/test RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.1.6 (LIVE555 Streaming Media v2014.01.13)
Accept: application/sdp

RTSP/1.0 200 OK
Content-Length: 227
CSeq: 3
Server: Packet Ship RTSP Server v3.1.8
Date: Thu, Jul 23 2015 07:32:45 GMT
Content-Type: application/sdp

v=0
o=- 15662137543711219903 15662137543711219903 IN IP4 192.168.0.216
s=Packet Ship RTSP session: test
c=IN IP4 192.168.0.216
t=0 0
a=range:npt=0-5637.16
a=control:rtsp://192.168.0.216/test
b=AS:3880
m=video 0 udp 33
--
SETUP rtsp://192.168.0.216/test/ RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.1.6 (LIVE555 Streaming Media v2014.01.13)
Transport: RAW/RAW/UDP;unicast;client_port=40888-40889

RTSP/1.0 200 OK
Content-Length: 0
CSeq: 4
Server: Packet Ship RTSP Server v3.1.8
Date: Thu, Jul 23 2015 07:32:45 GMT
Session: 57c7c0ccf3bc0014;timeout=50
Transport: RAW/RAW/UDP;unicast;client_port=40888-40889;source=0.0.0.0;server_port=34364
Range: npt=0-5637.16
--
PLAY rtsp://192.168.0.216/test RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.1.6 (LIVE555 Streaming Media v2014.01.13)
Session: 57c7c0ccf3bc0014
Range: npt=0.000-

RTSP/1.0 200 OK
Content-Length: 0
CSeq: 5
Server: Packet Ship RTSP Server v3.1.8
Date: Thu, Jul 23 2015 07:32:45 GMT
Range: npt=0-5637.16
--
GET_PARAMETER rtsp://192.168.0.216/test RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.1.6 (LIVE555 Streaming Media v2014.01.13)
Session: 57c7c0ccf3bc0014

RTSP/1.0 200 OK
Content-Length: 0
CSeq: 6
Server: Packet Ship RTSP Server v3.1.8
Date: Thu, Jul 23 2015 07:32:45 GMT
Content-type: text/parameters
--
Comment 5 Tim-Philipp Müller 2015-07-23 08:46:20 UTC
And what is the data actually streamed? MPEG-TS? something else?
Comment 6 ianw21 2015-07-23 14:35:50 UTC
Yes, MPEG-TS.
Comment 7 Nicolas Dufresne (ndufresne) 2015-07-23 15:13:30 UTC
Arguably, we could expose this as a ANY pad (just like what comes out of filesrc, udpsrc). If playbin typefind path works, it would "theorically" just work. If it's not discoverable, it will just fail.
Comment 8 Nicolas Dufresne (ndufresne) 2015-07-23 15:14:18 UTC
Do you have instruction on how to setup VLC/Liver555 server for that ?
Comment 9 ianw21 2015-07-24 14:49:31 UTC
The media server I'm using is packetship. I don't know how the media format is set with live555 media server, though I can change it by editing OnDemandServerMediaSubsession.cpp
Comment 10 Vivia Nikolaidou 2018-05-06 11:07:16 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide a testcase for this to be reproduced locally by us.
Thanks!