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 578475 - mmssrc: Non-interruptible and no timeout for connection attempts
mmssrc: Non-interruptible and no timeout for connection attempts
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 611105 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-09 11:40 UTC by Maxim Levitsky
Modified: 2018-11-03 13:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Maxim Levitsky 2009-04-09 11:40:39 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
Comment 1 Wim Taymans 2009-04-09 16:30:06 UTC
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://
Comment 2 Maxim Levitsky 2009-04-09 16:40:08 UTC
Why not?

This seems to be exctly what is needed
Comment 3 Edward Hervey 2009-04-23 10:15:26 UTC
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://

Comment 4 Maxim Levitsky 2009-05-02 23:34:59 UTC
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)

Comment 5 Edward Hervey 2009-05-07 10:08:11 UTC
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).
Comment 6 Sebastian Dröge (slomo) 2009-09-10 08:56:47 UTC
What's the state of this bug?
Comment 7 Edward Hervey 2009-09-10 08:59:53 UTC
We should add a timeout in mmssrc :)
Comment 8 Mark Nauwelaerts 2010-09-15 08:43:32 UTC
mmssrc is in -bad (and likely libmms in troubles)
Comment 9 Wim Taymans 2013-02-06 12:32:00 UTC
*** Bug 611105 has been marked as a duplicate of this bug. ***
Comment 10 Edward Hervey 2013-08-23 11:59:16 UTC
Can someone confirm this is still an issue with git ?
Comment 11 Guillaume Desmottes 2014-12-23 15:13:14 UTC
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.
Comment 12 Sebastian Dröge (slomo) 2014-12-23 15:17:42 UTC
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.
Comment 13 GStreamer system administrator 2018-11-03 13:04:15 UTC
-- 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.