GNOME Bugzilla – Bug 168390
data caching (queue) breaks mms/asf
Last modified: 2005-03-31 09:37:11 UTC
I have problems getting mms wmav2 audio streams to work with gstreamer-0.8.9 gst-plugins-0.8.7 gst-ffmpeg-0.8.3 assuming, for example $WMA=mms://213.200.75.252/antenne1$livestream.wma The following works: gst-launch-0.8 mmssrc location=$WMA ! filesink location=foo gst-launch-0.8 filesrc location=foo ! ffdemux_asf ! ffdec_wmav2 ! alsasink BUT the following does not play sound: gst-launch-0.8 mmssrc location=$WMA ! ffdemux_asf ! ffdec_wmav2 ! alsasink Seems like ffdemux_asf cannot link to ffdec_wmav2: INFO (0x80508f0 - 308125:58:04.590181000) GST_PIPELINE(16213) ./grammar.y(413):gst_parse_perform_link: linking ffdemux_asf0:(any) to ffdec_wmav20:(any) (0/0) with caps "(NULL)" INFO (0x80508f0 - 308125:58:04.593156000) GST_ELEMENT_PADS(16213) gstelement.c(1893):gst_element_link_pads_filtered: trying to link element ffdemux_asf0:(any) to element ffdec_wmav20:(any) INFO (0x80508f0 - 308125:58:04.596209000) GST_ELEMENT_PADS(16213) gstelement.c(1381):gst_element_get_static_pad: no such pad 'audio_%02d' in element "ffdemux_asf0" INFO (0x80508f0 - 308125:58:04.602082000) GST_ELEMENT_PADS(16213) gstelement.c(1841):gst_element_get_compatible_pad_filtered:<ffdemux_asf0> Could not find a compatible pad to link to ffdec_wmav20:sink
"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.
I bet it happens for any live stream, since we're (libmms) setting offset based on packet_seq, which seems to be set to $INSANELY_HIGH_VALUE for long running live streams. I'll need to see what is the logic behind doing it that way (it's inherited code), should fix that in a short while, at the very least tomorrow.
Created attachment 38346 [details] [review] patch for libmms fixing that Commited to latest CVS in libmms, but while you're waiting for anon to sync, here's a patch fixing this issue. Small testing shows everything should work, please test if I didn't break anything.
So, uh, it still doesn't work with playbin. It never gets past "Waiting for the state change..." stage (to be exact, it plays few (1 or 2) very short bursts of audio, but nothing more. Never changes the state though (?)). Decodebin works, however. May, or may not be related to bug 169436. Will debug it more tomorrow, for now messed up offsets should be fixed. One semi-related note however, when I omit audioconvert ! audioscale part, it doesn't fail to link, but idly spins with 100% CPU. This shouldn't happen.
Better, we get past typefinding, but we re-buffer all the time. Either we misalign a byte somewhere or timestamps are screwed up...
+ Trace 56529
That looks fairly suspicious, and happens when reading using playbin. Looks a lot like misaligned data, but I can't see where. Queue doesn't drop data. However, the buffering is still the easiest target, since it's the only difference between decodebin and playbin. Also, disabling buffering fixes it. So either we drop data somewhere, we reverse buffer order, we drop a download bit, or something like that...
*** Bug 169436 has been marked as a duplicate of this bug. ***
I've moved caching downstream the pipeline. Bug 136959 discusses the queue-implementation bug further, so I'll mark this as fixed (MMS works again).