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 600020 - mmssrc, retry, timeout
mmssrc, retry, timeout
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.24
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-29 12:19 UTC by Nicola
Modified: 2013-07-22 14:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicola 2009-10-29 12:19:20 UTC
Please test with mms url mms://scry.dubuque.k12.ia.us:1755/

it works with mplayer and doesn't work with gstreamer:

gst-launch-0.10 -v mmssrc location=mms://scry.dubuque.k12.ia.us:1755/ ! decodebin ! autovideosink

Impostazione della pipeline a PAUSED ...
ERRORE: la pipeline non vuole mettersi in pausa.
Impostazione della pipeline a NULL ...
Freeing pipeline ...

This is very long to get the stream. even with mplayer.
If you tcpdump on port 1775, you will see that mplayer resend initial mms request after a timeout whereas gstreamer does not.

Gstreamer just get stuck while mplayer retries.

regards
Nicola
Comment 1 Nicola 2009-11-03 04:50:00 UTC
Please note that the mms url I posted is public available (works with mplayer) so anyone can test it,

Nicola
Comment 2 Nicola 2010-02-03 17:27:09 UTC
Any news about this? Can the bug at least be confirmed?
Comment 3 Tim-Philipp Müller 2010-02-04 10:06:22 UTC
Indeed, mplayer will play it, but only after a ridiculously long time. At that point 99% of all users will already have given up waiting.

Re-sending an initial handshake if no data has been received on an established connection for a while is something that would need to be done at the libmms level. GStreamer can't do much about that.

However, I'll keep the bug open, since it's clearly something that doesn't work right yet, and I still intend on getting rid of libmms and dealing the mms connection ourselves.
Comment 4 Nicola 2010-02-04 11:02:24 UTC
Reported upstream:

https://bugs.launchpad.net/libmms/+bug/517007

thanks
Nicola
Comment 5 Nicola 2010-02-14 18:19:39 UTC
Please note that vlc and mplayer works really well if you use this url:

mmsh://scry.dubuque.k12.ia.us:1755/

I think they first try mms and after timeout mmsh,

Nicola
Comment 6 Nicola 2010-03-06 12:56:27 UTC
Looking at this ubuntu bug:

https://bugs.launchpad.net/ubuntu/+source/libmms/+bug/284821

seems that ubuntu hardy was able to play mmsh stream so this seems a regression in handling mms/mmsh stream in gstreamer, with tha latest gstreamer version I have this error:

gst-launch-0.10 -v mmssrc location=mmsh://scry.dubuque.k12.ia.us:1755/ ! decodebin ! autovideosink
Impostazione della pipeline a PAUSED ...
ERRORE: la pipeline non vuole mettersi in pausa.
ERRORE: dall'elemento /GstPipeline:pipeline0/GstMMS:mms0: Could not connect to streaming server.
Informazioni di debug aggiuntive:
gstmms.c(461): gst_mms_start (): /GstPipeline:pipeline0/GstMMS:mms0:
A redirect message was posted on the bus and should have been handled by the application.
Impostazione della pipeline a NULL ...
Esecuzione di free sulla pipeline...

while both vlc and mplayer works fine,

Nicola
Comment 7 Nicola 2010-09-18 10:11:52 UTC
it works now with libmms 0.6
Comment 8 Edward Hervey 2013-07-22 14:15:50 UTC
Closing. Can't reproduce and according to comment #7 it was fixed upstream.