GNOME Bugzilla – Bug 739391
rtspsrc: rtsp wms streams not working 1.3.1 onwards [regression]
Last modified: 2018-11-03 14:55:23 UTC
Rtsp wms streams not working from version 1.3.1 onwards (not working in 1.4.3 either). It was working in version 1.2.4. I can see that there are quite a few changes in gstrtspsrc.c between versions 1.24 and 1.3.1. In version 1.3.1 (and onwards), for rtsp wms streams the gst_rtspsrc_stream_configure_transport() function in gstrtpssrc.c is not getting called at all. I downloaded source of gst-plugins-good versions 1.2.4, 1.3.1 and 1.4.3 and built them all on my x86, Ubuntu Linux 14.04. And tried the following pipeline ./bin/gst-launch-1.0 rtspsrc location="rtsp://a1989.l1140549988.c11405.e.lm.akamaistream.net/D/1989/11405/v0001/reflector:49988" ! fakesink dump=1 It gives fakesink dump output for version 1.2.4, but fails for versions 1.3.1 and 1.4.3. Also tested with stream rtsp://a1671.l2063252432.c20632.g.lm.akamaistream.net/D/1671/20632/v0001/reflector:52432
Still broken with 1.4 and git master. Works with 1.2. $ gst-play-1.0 rtsp://195.134.224.231/snowboard_100.wmv Now playing rtsp://195.134.224.231/snowboard_100.wmv Pipeline is live. ERROR The stream is of a different type than handled by this element. for rtsp://195.134.224.231/snowboard_100.wmv ERROR debug information: gstasfdemux.c(957): gst_asf_demux_chain_headers (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstASFDemux:asfdemux0: The stream is of a different type than handled by this element.
First part of the patch: commit 852c040c89bd99bd11598a628934a2b48b1e9a64 Author: Wim Taymans <wtaymans@redhat.com> Date: Tue Feb 3 17:35:52 2015 +0100 rtspsrc: fix container handling We detect a container correctly now so we need to revert the weird check there was before. Use gst_rtspsrc_stream_push_event() to push the caps event on the right pad. See https://bugzilla.gnome.org/show_bug.cgi?id=739391
It still doesn't work with decodebin because of it delays the linking and we lose the first buffer with the asf header. Works now if manually making a pipeline.
See https://bugzilla.gnome.org/show_bug.cgi?id=745599#c8 for a fix for something that was broken by this commit.
The part of the commit about buffering might not be right but IRC discussing didn't give any conclusions :) Should be reconsidered, or the comment above it should be removed. <wtay> slomo, also unsure if the comment about the buffering is still true, in general, I think you want buffering for container streams <slomo> wtay: ok, then maybe the container condition should go away completely? <slomo> because otherwise you will never buffer for non-container streams <andoni> bilboed, this could avoid conflicts of recipes going through the fetch step for the same local sources <wtay> slomo, that's a good thing, you don't want to buffer <slomo> i see <wtay> don't you think? <wtay> or you think buffering for a non-live stream is better because of our crappy resampling? <slomo> i don't know :) i have no opinion on that yet, other than that the buffering code in jitterbuffer looked confusing to me last time i looked ;)
All the Windows Media RTSP streams I had seem to be down. Does anyone have URLs that are still up?
un-blocker-ing this, since it's not a regression from 1.4 but has been broken for longer (and also we can't fix it without test streams).
here are some RTSP test streams with WMS: rtsp://windowsmedia.zdv.uni-mainz.de/zdvsys/Samples/pinball.wmv rtsp://windowsmedia.zdv.uni-mainz.de/zdvsys/Samples/racecar_300.wmv rtsp://windowsmedia.zdv.uni-mainz.de/zdvsys/Samples/snowboard_100.wmv rtsp://windowsmedia.zdv.uni-mainz.de/zdvsys/Samples/snowboard_300.wmv
I did a regression test. Something wrong happens after this commit (3/06/2014): "rtspsrc: skip streams with same control url" commit-ID: 224239096df26f9d32c7172c9786ef82aeac1367 in gstrtspsrc.c file, new_manager_pad() function, all_added flag remains false. so, please clarify if setup, added and container parameters of ostream are set correctly.
Thanks a lot for the sample URLs and for bisecting, that's helpful.
this issue can be reproduced with gstreamer 1.6.0.
Still seems to fail with master. Works with vlc. $ gst-launch-1.0 rtsp://windowsmedia.zdv.uni-mainz.de/zdvsys/Samples/snowboard_300.wmv Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Progress: (open) Opening Stream Progress: (connect) Connecting to rtsp://windowsmedia.zdv.uni-mainz.de/zdvsys/Samples/snowboard_300.wmv Progress: (open) Retrieving server options Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 Progress: (request) SETUP stream 2 Progress: (request) SETUP stream 2 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource. Additional debug info: gstrtspsrc.c(4767): gst_rtspsrc_loop_udp (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: The server closed the connection.
*** Bug 788267 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/138.