GNOME Bugzilla – Bug 585576
[souphttpsrc] initially reports all servers as seekable
Last modified: 2009-07-16 17:37:26 UTC
There was this nice fix for mp3parse that it doesn't build an index table over time when it cannot seek anyways, which is supposed to stop the unbounded memory growth when listening to internet radio (for embedded devices, extra CPU load is also a factor). Problem is that souphttpsrc initially assumes that servers support seeking. Try: GST_DEBUG=mp3parse:4 gst-launch-0.10 playbin2 uri=http://gffstream.ic.llnwd.net/stream/gffstream_stream_wdr_einslive_a 2>&1|fgrep index The server sends no Content-Length header, so there is no stream duration (which makes it questionable to assume seekability(?)). Either souphttpsrc should have better prediction of seekability or maybe mp3parse should suppress index table building when the upstream duration query fails.
Yes, I don't think the current behaviour makes that much sense. While technically correct, I don't really see a use case for this; also, it's confusing for downstream elements and hence just complicates things needlessly for little gain afaics.
I've put some patches for mp3parse into bug #585956, since -ugly is frozen right now.
commit 226a12505683fdfc6e3fc403ed55fe8f8e56f470 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Jul 16 19:35:44 2009 +0200 souphttpsrc: Only assume seekability if the server provides Content-Length Previously seekability way always assumed until the first seek actually failed. Now we assume that all servers are not seekable unless they provide a Content-Length header. If a seek fails after that we continue to assume no seekability. Fixes bug #585576.