GNOME Bugzilla – Bug 722185
souphttpsrc: racy "server does not support seeking" error
Last modified: 2014-02-19 16:03:43 UTC
Hello. I use Gstreamer 1.2.1 for Android to play HLS stream. But this bug affects gst-plugins-good in general. more precisely souphttpsrc element. Reproduced it on desktop as well. My pipeline looks like this, souphttpsrc ! hlsdemux ! mpegaudioparse ! mad ! audioconvert ! audioresample ! autoaudiosink or just playbin My code is Android Tutorial5 with just another url. But you can reproduce it on comandline with gst-launch Problem is stream starts playing only once in 3-5 tries. The rest fail with error: gstsouphttpsrc.c:888:gst_soup_http_src_got_headers_cb:<mysource> error: Server does not support seeking. gst_soup_http_src_got_headers_cb:<mysource> error: Server does not accept Range HTTP header, URL: https://ec-media-hls.soundcloud.com/playlist/swx3WdvxAQ9W.128.mp3/playlist.m3u8 Server really does not support ranges. As it should not to serve m3u8 5 kilobytes playlists. Those times playing failed I see two playlist.m3u8 request on server. First one is how it should be, but the extra second one has Range: bytes=1001- where 1000 is the total length of playlist received with previous request. Server ignore it and return whole playlist again without any content ranges in response. Once playback stars there is only one playlist request. All hls segments are requested without ranges. Workaround. I've tried putting some static HLS content on server that support range requests - it works fine. To reproduce try gst-launch-1.0 playbin uri=https://ec-media-hls.soundcloud.com/playlist/swx3WdvxAQ9W.128.mp3/playlist.m3u8
*** Bug 722186 has been marked as a duplicate of this bug. ***
*** Bug 722184 has been marked as a duplicate of this bug. ***
I have been working around this very same issue but got no solution (neither a detailed diagnose) yet. Things I have figured out that might be related to the problem at hand though: souphttpsrc code does not check for a accept-ranges header from the server to rule on whether it can issue range requests, it seems to derive this from the content-length header alone (I will take a look tomorrow at the spec, it might be that the accept-ranges header is not mandatory?) souphttpsrc code adds range request headers regardless of whether the server supports range requests or not souphttpsrc code aborts during playback if it finds a range request cannot be satisfied regardless of whether the server supports range requests to begin with. I'm rather unsure on what's the expected behavior here As a general comment, the code is using an asynchronous soup session (There's also a synchronous mode which might be more suitable for a gstreamer element). This been said, I see quite some state changes from the soup callback functions without any locking which at least seems odd but I haven't been able to relate this with this failure to perform playback reliably. My test case is webm streaming through icecast with the following pipelines: push: gst-launch-1.0 webmmux streamable=true name=mux ! shout2send mount=/stream.webm port=8000 ip=xxx.mooo.com username=source password=xxxx uridecodebin uri=file:///somevideofile name=d d. ! queue ! audioconvert ! vorbisenc ! mux. d. ! queue ! videoconvert ! vp8enc ! mux. pull: gst-launch-1.0 souphttpsrc location=http://xxx.mooo.com:8000/stream.webm iradio-mode=false is-live=true ! matroskademux name=d d. ! queue ! vp8dec ! videoconvert ! xvimagesink d. ! queue ! vorbisdec ! audioconvert ! pulsesink As a side question. What should normally happen if the combined push process is slower than the playback one? is this behavior server dependent? Will attach a full log tomorrow in case someone wants to take a look and keep you posted on my findings if any.
I kinda resolved this bug. The server just did not return a content-lengh. once I put this header in place it solved an issue. Still playlist my understanding is that the content-lengh header is not a part of HLS spec. And gstreamer should not rely on it. Other players like VLC or quicktime swallow such urls and play correctly.
Yes, it should work fine without. Why did it not always error out then? Was it potluck which server answered the request? Or is there a timing issue inside souphttpsrc? (Asked differently: do you have a test scenario where it always errors out?)
that is something i do not understand. failed occurred much more often. but success play could have happen on first try with same probability on Nth.
I can't reproduce this here and also judging from the code it does not make much sense anymore. Can someone provide a useful testcase for reproducing it?
Reproduced here now, and looking into it
commit 9cac68709a5bc3d01564fa58ee1afc8bc886205c Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Feb 12 12:39:10 2014 +0100 souphttpsrc: Retry connection if we're finished before the content size only if we actually have a content size https://bugzilla.gnome.org/show_bug.cgi?id=722185
*** Bug 724717 has been marked as a duplicate of this bug. ***