[gstreamer-bugs] [Bug 168390] mms://wma pipeline does not link properly

bugzilla-daemon at bugzilla.gnome.org bugzilla-daemon at bugzilla.gnome.org
Sun Mar 6 04:04:42 PST 2005


Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=168390
 GStreamer | don't know | Ver: 0.8.9





------- Additional Comments From Ronald Bultje  2005-03-06 07:04 -------
"gst-launch-0.8 mmssrc location=mms://213.200.75.252/antenne1\$livestream.wma !
asfdemux ! ffdec_wmav2 ! audioconvert ! audioscale ! alsasink device=dmix" works
for me (and I get sound), maybe because of my previous patch in another bug report.

The funny (or sad) thing is that playbin (or totem, for that matter) doesn't
work. It buffers fine, but then it fails to start actual data flow when the
buffer is filled. I don't know why yet, but from a first series of events, it
seems like it's stuck in source event handling. What happens is that as soon as
we start running, queue pushes data to its peer (typefind, in decodebin), and
typefind does a seek. However, from this point on, it does nothing *but*
seeking. It never gets around to actual typefinding. I've looked briefly at
typefind output, but cannot really see why it gets into this infinite loop. I
think it's because mmssrc sets invalid buffer offsets on outgoing buffers
(doesn't start at zero). However, on the other hand, typefindelement doesn't
handle this case all too well, it should just error out. I've looked briefly at
typefindelement's code and am heavily confused. I'd appreciate some help there.
Mmssrc is an easy fix, I think.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.




More information about the Gstreamer-bugs mailing list