GNOME Bugzilla – Bug 342540
[playbin] Improve network buffering
Last modified: 2006-12-09 19:43:07 UTC
Please describe the problem: Go to rushlimbaugh.com (I know, I don't listen to him either, but I was sent a supposedly funny parody) Click on any of his audio streams and try to play them (ASX.) The audio plays for a couple of seconds and quits working. I'd include a link, but they become subscriber only after a couple of days. You'll have to find one yourself. I'm sure if its broken for that website its broken for others. Steps to reproduce: Actual results: Expected results: Does this happen every time? Yes Other information:
*** Bug 342539 has been marked as a duplicate of this bug. ***
Works fine for me. What versions are your GStreamer plugins packages? What's the output of these commands: $ gst-inspect-0.10 asfdemux | grep Version $ gst-inspect-0.10 playbin | grep Version $ gst-inspect-0.10 ffmpeg | grep Version ? What type of internet connection do you have (dial-up/cable/broadband)? When you try to listen to the stream, do you have enough bandwidth for it? Does totem show 'buffering' a lot at the bottom?
asfdemux 0.10.3 playbin 0.10.7 ffmpeg 0.10.1 I have 6Mbps down with my cable modem :-) I grabbed another audio stream and didn't see the problem, but after I dragged the thumb around a few times it helped to cause the problem. Also, I noticed that I wasn't able to move the audio to a later point in the stream. It would be nice to be able to do that.
I tested this myself today. Using a pipeline like this I saved the stream to disk: gst-launch-0.10 mmssrc location="mms://a1171.v5020c.c5020.g.vm.akamaistream.net/7/1171/5020/v0001/rushlimb.download.akamai.com/5020/clips/06/06/060106_3_haditha1.wma" ! filesink location=rush.wma Playing locally all files played fine. Only when playing from the site did I get the stuttering problem. My guess is that the server site is having trouble keeping the flow clear and we are not buffering enough/well enough to handle this bursty traffic.
I don't see it with other OSes and I have found that Akamai has good servers so I think the problem is the buffering algorithms. I know that real, wmplayer, etc. have worked quite a bit on doing good buffering (and starting the playing up right away rather than having long delays) so I think gstreamer needs a bit more love here.
FWIW, asf format contains an entry in the headers specifying how much data you should buffer before playing. I imagine mplayer/xine/m$ players use that value, maybe we should use it in gstreamer too.
You don't necessarily need to use that data. It seems like you just give yourself 3 seconds of buffering or something. And when you move the scroll thumb around, the audio skipping gets really bad, so I think it might be some basic regression thats broken all buffering.
This bug is still unconfirmed, though Christian Schaller has also repro'ed it. I often find buffering screw-ups with totem-gstreamer and I hope it is being worked on.
Whether a bug is UNCONFIRMED or NEW doesn't really matter too much to us, we don't attribute too much significance to that. Those buffering issues are a known problem with playbin. Playbin should pause the pipeline while re-buffering until it has enough data, currently the pipeline keeps running (and the clock advances), which isn't right. It's on the radar and being worked on.
Change subject, marking normal.
*** Bug 345014 has been marked as a duplicate of this bug. ***
I can confirm that this behaviour is also present with MPEG2/4 over UDP or RTP. The encoders are on the local network and the decoders work without "stutering". So bandwith is no problem here. The udpsrc makes use of the SELECT function? is this necessary? This slowes the connection with a factor 2 or more. (Because the polling behaviour)
UDP/RTP is an entirely different beast, any buffering should be done in a session manager and the playback rate is controlled by such session manager. Can you give more information why a select/poll call would slow down the connection speed? We need the poll to interrupt the element when shutting down. In general buffering has been improved in current CVS, can you retry?
It works a lot better now, but I still cannot seek through an ASX stream. Should I enter a separate bug for that?
> It works a lot better now Great, thanks for confirming. Closing this bug then. > but I still cannot seek through an ASX stream. > Should I enter a separate bug for that? Yes, please file a new bug for this. Implementing seeking over the network in asfdemux isn't high priority though (there are more urgent things that need fixing in asfdemux) and needs changes in the http sources as well.
I should also mention that proper buffering needs application support and you need a recent totem version for this to work properly.