GNOME Bugzilla – Bug 727088
asfdemux: gstreamer can't play certain mms streams (no output buffers created)
Last modified: 2016-12-28 11:22:01 UTC
Created attachment 272991 [details] Output of gst-launch-1.0 trying to play mms stream Overview: When trying to play an mms stream: mms://wmlive-nonacl.bbc.net.uk/wms/nations/cymru?BBC-UID=55c34034d77f2bd5a8ae10fd918c5e5036c00fb230e011d4746f398762b666bb&SSO2-UID= with gst-launch-1.0 the pipeline starts prerolling, but then it seems to halt. The stream uri was taken from: http://www.bbc.co.uk/radio/listen/live/rc.asx But this has also happened with uris from: http://www.bbc.co.uk/radio/listen/live/rf.asx http://www.bbc.co.uk/radio/listen/live/rng.asx http://www.bbc.co.uk/radio/listen/live/rs.asx http://www.bbc.co.uk/radio/listen/live/ru.asx http://www.bbc.co.uk/radio/listen/live/rw.asx Steps to reproduce: Try to play the stream with the following command: " gst-launch-1.0 -v playbin uri="mms://wmlive-nonacl.bbc.net.uk/wms/nations/cymru?BBC-UID=55c34034d77f2bd5a8ae10fd918c5e5036c00fb230e011d4746f398762b666bb&SSO2-UID=" " Actual results: Setting pipeline to PAUSED ... /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0 /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-size = -1 /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-duration = -1 /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: use-buffering = false /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: download = false /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: uri = mms://wmlive-nonacl.bbc.net.uk/wms/nations/cymru?BBC-UID=55c34034d77f2bd5a8ae10fd918c5e5036c00fb230e011d4746f398762b666bb&SSO2-UID= /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: connection-speed = 0 /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: source = "\(GstMMS\)\ source" Pipeline is PREROLLING ... /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstMMS:source.GstPad:src: caps = video/x-ms-asf /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/x-ms-asf /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = video/x-ms-asf /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:sink: caps = video/x-ms-asf /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink: caps = video/x-ms-asf /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstASFDemux:asfdemux0.GstPad:sink: caps = video/x-ms-asf Expected results: It starts playing. Taken from gst-launch-0.10 output: I presume it would be something like this. Additional lines have been removed. Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock Build & Platform: 3.8.0-36-generic #52~precise1-Ubuntu SMP Mon Feb 3 21:56:56 UTC 2014 i686 i686 i386 GNU/Linux $ gst-launch-1.0 --version gst-launch-1.0 version 1.2.1 GStreamer 1.2.1 https://launchpad.net/distros/ubuntu/+source/gstreamer1.0 Additional builds and platforms: When trying to play the stream with gst-launch-0.10 (version: 0.10.36) it plays nicely. Additional information: When debugging gst-launch-1.0 with gdb and the gst-launch receives a SIGINT and then later continuing the program's work it starts playing the stream, but later after some time (seems to be related to the duration the program is interrupted) we get EOS from element "playbin0". You can also see this from the attached log. When you don't interrupt the program it halts at line 159. The rest happens after you continue from the interruption.
This looks like a bug in asfdemux. It gets data all the time but never outputs it. See the output with GST_DEBUG=asf*:6
Can you still reproduce this, and, if so, with what stream ? The examples above seem to be replaced with mp3 via http now, and a quick web search does not find a working (as in, can connect) mms stream which fails to play.
Closing this bug report as no further information has been provided. (Sorry we didn't get around to investigating this in time, and unfortunately Sebastian didn't save any info). Please feel free to reopen this bug report if you can provide streams that happens with again. If not, I'm sure someone else will run into this and file a new bug. Thanks!