GNOME Bugzilla – Bug 401173
[asfdemux] Stream doesn't play, stuck on first frame
Last modified: 2009-05-24 20:52:59 UTC
This video stream does not play correctly in GStreamer, it seems to get stuck on the first frame, sound isn't played either. mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv It's playable in MPlayer and in Totem if the stream is dumped, could this be a problem with the mms support, similar to bug 386129? I'm using 0.10.4 of gst-plugins-bad. GST_DEBUG=mmssrc:5 gst-launch-0.10 playbin uri=mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv Setting pipeline to PAUSED ... 0:00:00.179345000 14660 0x8051a08 DEBUG mmssrc gstmms.c:287:gst_mms_start:<source> Trying mms_connect (mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv) 0:00:01.214538000 14660 0x8051a08 DEBUG mmssrc gstmms.c:301:gst_mms_start:<source> Connect successful Pipeline is PREROLLING ... 0:00:01.216049000 14660 0x811a680 DEBUG mmssrc gstmms.c:242:gst_mms_create: reading 2048 bytes 0:00:01.216116000 14660 0x811a680 DEBUG mmssrc gstmms.c:263:gst_mms_create: Returning buffer with offset 0 and size 2048 0:00:01.234120000 14660 0x811a680 DEBUG mmssrc gstmms.c:242:gst_mms_create: reading 2048 bytes 0:00:01.234300000 14660 0x811a680 DEBUG mmssrc gstmms.c:263:gst_mms_create: Returning buffer with offset 2048 and size 2048 0:00:01.234447000 14660 0x811a680 DEBUG mmssrc gstmms.c:242:gst_mms_create: reading 2048 bytes 0:00:01.356100000 14660 0x811a680 DEBUG mmssrc gstmms.c:263:gst_mms_create: Returning buffer with offset 4096 and size 2048 0:00:01.684805000 14660 0x811a680 DEBUG mmssrc gstmms.c:242:gst_mms_create: reading 2048 bytes 0:00:01.684997000 14660 0x811a680 DEBUG mmssrc gstmms.c:263:gst_mms_create: Returning buffer with offset 6144 and size 2048 0:00:01.691926000 14660 0x811a680 DEBUG mmssrc gstmms.c:242:gst_mms_create: reading 2048 bytes 0:00:01.692084000 14660 0x811a680 DEBUG mmssrc gstmms.c:263:gst_mms_create: Returning buffer with offset 37072 and size 2048 0:00:01.692265000 14660 0x811a680 DEBUG mmssrc gstmms.c:242:gst_mms_create: reading 2048 bytes 0:00:01.692467000 14660 0x811a680 DEBUG mmssrc gstmms.c:263:gst_mms_create: Returning buffer with offset 39120 and size 2048
Or, more likely, is it a dupe of bug 353116?
This stream has a similar problem, mms://qstream-wm.qbrick.com/00451/nyheter/20070511NyheterDN.wmv This is a general problem with all the streams on this page, http://webbtv.dn.se/index.aspx (only in Swedish). It appears to be stuck on the first frame, but if you wait long enough (for the whole file to be downloaded?) it eventually starts to play. Maybe this bug belongs to the -ugly plugins?
It looks like it's the same problem as in bug #415801 (the stream header advertises streams for which we don't get data, which playbin doesn't handle very well). I know what the problem is, just looking for the best way to fix it. Works for me locally already, just need to clean it up a bit and test it. Should hopefully be fixed soon. Although there might possibly be another problem here. According to the stream headers, there's supposed to be a video stream as well, but we never receive any video data, only audio data, so maybe mmssrc needs to select this explicitly or something, not sure. mplayer gets the video stream.
Sven, it plays fine for me with latest gstreamer. Could you recheck please?
I'm using CVS of most of the GStreamer modules now, and I'm still not having any luck. Could this be a problem related to an external dependency like libmms instead?
I have libmms-0.3 and I don't think there is active development in libmms. As you get the first frame it can't be the network setup (proxy etc.). Can you check that you have an up-to-date enough gst-plugin-ugly, so that you definitely have the fix for bug #353116. If you have, you could run GST_DEBUG="*:4" gst-launch 2>debug.log ... and post the log here.
I tried CVS of -ugly as of today, still no change. I'm attaching the log of the command. As for libmms, I'm using 0.3, but with three patches from my distro; http://svn.debian.org/wsvn/pkg-multimedia/unstable/libmms/debian/patches/ (scroll down a bit).
Created attachment 93239 [details] debug log
Hmm, lg is really huge :/ I run this: $ GST_DEBUG="*:3,mms*:4" gst-launch mmssrc location=mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv ! decodebin ! xvimagesink and it gets stuck: 0:00:00.098540000 12161 0x804e050 INFO GST_STATES gstelement.c:2141:gst_element_continue_state:<typefind> posting state-changed READY to PAUSED 0:00:00.098593000 12161 0x804e050 INFO GST_STATES gstbin.c:2110:gst_bin_change_state_func:<decodebin0> child 'typefind' changed state to 3(PAUSED) successfully 0:00:00.098645000 12161 0x804e050 INFO GST_STATES gstbin.c:2116:gst_bin_change_state_func:<pipeline0> child 'decodebin0' is changing state asynchronously to PAUSED 0:00:00.098699000 12161 0x804e050 DEBUG mmssrc gstmms.c:307:gst_mms_start:<mms0> Trying mms_connect (mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv) with bandwidth constraint of 2147483647 bps On the other hand: $ mplayer mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv ... Playing mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv. STREAM_ASF, URL: mms://qstream-wm.qbrick.com/00928/sthlm/dokumentar/dokumentarfilm/070123livraddarna.wmv Resolving qstream-wm.qbrick.com for AF_INET6... Couldn't resolve name for AF_INET6: qstream-wm.qbrick.com Resolving qstream-wm.qbrick.com for AF_INET... Connecting to server qstream-wm.qbrick.com[194.14.243.153]: 1755... and it gets stuck there too. On the site you mention in comment 2, I cannot find the links to mms streams.
Weird, it does work for me with mplayer. As for the site in comment 2, here's a direct link to an mms stream; mms://qstream-wm.qbrick.com/00451/nyheter/20070511NyheterDN.wmv
I'm now using libmms 0.4 (with no patches) and the problem remains. Meanwhile, the stream mentioned in my first comment seems to be gone, here's another one from the same source: mms://qstream-wm.qbrick.com/00928/nyheter/2007/rapportsarskronika2007.wmv
I can confirm this bug here with the latest libmms and gstreamer CVS.
*** Bug 581625 has been marked as a duplicate of this bug. ***
Svens last link is dead, here is another one which will be up until january 2010. mms://wm0.c90805.cdn.qbrick.com/90805/kluster/20090104/N-2009-0104-OSTNYTT-ARSKRONIKA-DEL3WEB.wmv I still see this bug, with only the first frame being shown. However, if I run the following pipeline: gst-launch-0.10 mmssrc location=mms://wm0.c90805.cdn.qbrick.com/90805/kluster/20090104/N-2009-0104-OSTNYTT-ARSKRONIKA-DEL3WEB.wmv ! filesink location=test.wmv I can play back the test.wmv file using mplayer. So the mmssrc transfer seems to be working.
As mentioned in comment 2 it should also work if you just wait for the entire stream to be downloaded. See also comment 3 where Tim-Philipp Müller mentions this might be the same as bug 415801 which should be "fixed soon".
Everything works fine now with latest fixes to asfdemux and playbin2. Just tested the stream in comment #14
In what versions is this fixed? I'm still having this problem with ugly 0.10.11 and base 0.10.23.
It should be fixed in -ugly 0.10.12 (ie. -ugly git for now), according to the target milestone.
Thanks for the quick answer, I just grabbed -ugly from git and it seems to be working very well!