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 168390 - data caching (queue) breaks mms/asf
data caching (queue) breaks mms/asf
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.9
Other Linux
: Normal major
: 0.8.9
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 169436 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-02-24 14:07 UTC by Mathis Ahrens
Modified: 2005-03-31 09:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for libmms fixing that (3.77 KB, patch)
2005-03-06 22:42 UTC, Maciej Katafiasz
none Details | Review

Description Mathis Ahrens 2005-02-24 14:07:56 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
Comment 1 Ronald Bultje 2005-03-06 12:04:41 UTC
"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.
Comment 2 Maciej Katafiasz 2005-03-06 22:07:45 UTC
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.
Comment 3 Maciej Katafiasz 2005-03-06 22:42:09 UTC
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.
Comment 4 Maciej Katafiasz 2005-03-06 23:09:07 UTC
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.
Comment 5 Ronald Bultje 2005-03-06 23:24:00 UTC
Better, we get past typefinding, but we re-buffer all the time. Either we
misalign a byte somewhere or timestamps are screwed up...
Comment 6 Ronald Bultje 2005-03-07 10:52:14 UTC


  • #11 gst_bytestream_flush
    at bytestream.c line 455
  • #12 gst_asf_demux_process_chunk
    at gstasfdemux.c line 1487
  • #13 gst_asf_demux_process_segment
    at gstasfdemux.c line 938
  • #14 gst_asf_demux_handle_data
    at gstasfdemux.c line 1088

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...
Comment 7 Ronald Bultje 2005-03-12 22:51:30 UTC
*** Bug 169436 has been marked as a duplicate of this bug. ***
Comment 8 Ronald Bultje 2005-03-31 09:37:11 UTC
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).