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 377792 - rtspsrc tries to stream application/x-wms-rtx
rtspsrc tries to stream application/x-wms-rtx
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 0.10.5
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-21 14:47 UTC by Fabrice Triboix
Modified: 2006-11-28 11:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (3.95 KB, patch)
2006-11-28 10:14 UTC, Wim Taymans
committed Details | Review

Description Fabrice Triboix 2006-11-21 14:47:58 UTC
Please describe the problem:
The rtspsrc element opens an RTP/RTCP session for every "media" present in the RTSP/SDP (in reply to RTSP/DESCRIBE). In the case of the Windows Media platform, there is a media with a MIME type of "application/x-wms-rtx", which is Micro$oft-specific and does not send any RTP packet.
After 5 seconds (default timeout), rtspsrc complains that no packet is received on the stream and closes the whole session.

Steps to reproduce:
1. Have a running WMServer with a .wma file to be streamed
2. $ gst-launch rtspsrc location=rtsp://wmserver/file.wma ! fakesink
3. After 5 seconds, the following message appears and rtspsrc closes the connection (with a TEARDOWN):

Could not receive any UDP packets for 5.0000 seconds, maybe your firewall is blocking it. Retrying using a TCP connection.


Actual results:
rtspsrc wrongly concludes that the whole session is invalid and closes it.

Expected results:
The session carries on for the other streams (ex: audio, video, etc.)

Does this happen every time?
Yes

Other information:
The easiest solution I think is to close only the RTP session instead of the whole RTSP sessions. If all RTP sessions are closes, then rtspsrc indeed knows that this session is invalid/empty and should be closed.
Comment 1 Fabrice Triboix 2006-11-21 15:01:34 UTC
It should also be noted that rtspsrc does not retry with TCP, despite its claims!
Comment 2 Tim-Philipp Müller 2006-11-21 15:13:06 UTC
> It should also be noted that rtspsrc does not retry with TCP, despite its
> claims!

rtspsrc will just post a "redirect" element message on the bus, the application has to take care to catch those and try again with the new URI (totem does, but gst-launch doesn't yet AFAIK).
Comment 3 Wim Taymans 2006-11-28 10:14:03 UTC
Created attachment 77283 [details] [review]
proposed patch

This patch adds a new method that extensions can use to disabled the configuration of the transport of a stream. the WMS extension will nt configure x-wms-rtx streams.
Comment 4 Wim Taymans 2006-11-28 11:53:51 UTC
        * gst/rtsp/gstrtspsrc.c: (gst_rtspsrc_open):
        * gst/rtsp/gstrtspsrc.h:
        * gst/rtsp/rtspext.h:
        * gst/rtsp/rtspextwms.c: (rtsp_ext_wms_configure_stream),
        (rtsp_ext_wms_get_context):
        Add method so that extensions can choose to disable the setup of
        a stream.
        Make the WMS extension skip setup of x-wms-rtx streams. Fixes #377792.