GNOME Bugzilla – Bug 578475
mmssrc: Non-interruptible and no timeout for connection attempts
Last modified: 2018-11-03 13:04:15 UTC
Gstreamer has now asf depayloader, but totem won't play mms:// streams which are in fact rtsp. Something has to be done to detect this. In windows you can select which protocols to use (rtsp, mms ) windows first tries rtsp
Maybe we can do the same trick as pnm://, let the element (mmssrc) post a redirect message to rtsp:// when it cannot open the stream with mms://
Why not? This seems to be exctly what is needed
Completely forgot I fixed that 2 days ago :) commit a025f156a5d15c72138f18da78bcf9fffd9fda5f Author: Edward Hervey <bilboed@bilboed.com> Date: Tue Apr 21 16:48:39 2009 +0200 mmssrc: If the connection fails, emit a redirection msg to the rtsp equivalent. This should help fix the issue with Windows Media Server using rtsp... but still declaring the stream with mms://
Unfortunately this doesn't work for me. Problem is that server I deal with doesn't answer anything when mms connection is attempted, thus gstreamer just hangs, maybe after a 'hour' it will reconnect using rtsp. I tested (now finally have a vm with XP inside), and windows first tries rtsp. So its quite complicated (and since this is the way WMP works, there might be more servers of this kind)
maybe we need a way to make mmssrc timeout earlier. If it hasn't received meaningful data within 30s ... it should be considered as a dead stream (and switch to rtsp).
What's the state of this bug?
We should add a timeout in mmssrc :)
mmssrc is in -bad (and likely libmms in troubles)
*** Bug 611105 has been marked as a duplicate of this bug. ***
Can someone confirm this is still an issue with git ?
I'm facing a similar issue with mms://193.191.129.52/Archive/20140424-1_bb_pl.wmv which takes a while to connect but it's because libmms first try mmsh which times out. Using LIBMMS_TRY_MMS_FIRST=1 solves this. Btw this works fine with gst 1.2: gst-launch-1.0 playbin uri=rtsp://193.191.129.52/Archive/20140424-1_bb_pl.wmv but fails with master, not sure why: 0:00:02.372941298 14737 0x7f6ad40024a0 LOG asfdemux gstasfdemux.c:840:gst_asf_demux_identify_guid: ASF_OBJ_UNDEFINED 0x40000082-0x2305eb5d-0x06000000-0x00030100 0:00:02.372962511 14737 0x7f6ad40024a0 WARN asfdemux gstasfdemux.c:876:asf_demux_peek_object:<asfdemux0> Unknown object 40000082-2305eb5d-06000000-00030100 0:00:02.372982015 14737 0x7f6ad40024a0 WARN asfdemux gstasfdemux.c:953:gst_asf_demux_chain_headers:<asfdemux0> error: This doesn't seem to be an ASF file Anyway, how would you implement this timeout in mmssrc? mmsx_connect() is a blocking call so should we spawn a thread and use g_timeout_add() in it or is it a better way to do this in GStreamer? Also, we can't cancel the current mmsx_connect() so this may be a bit tricky to get right.
You can't use g_timeout_add() or anything like that from GStreamer as we don't require someone iterating the default GMainContext. I think the real solution to this would be to rewrite libmms with a proper async API.
-- 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-bad/issues/10.