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 722185 - souphttpsrc: racy "server does not support seeking" error
souphttpsrc: racy "server does not support seeking" error
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal major
: 1.2.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 722184 722186 724717 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-01-14 14:25 UTC by Alexander Zallesov
Modified: 2014-02-19 16:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alexander Zallesov 2014-01-14 14:25:22 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
Comment 1 Sebastian Dröge (slomo) 2014-01-14 15:04:59 UTC
*** Bug 722186 has been marked as a duplicate of this bug. ***
Comment 2 Sebastian Dröge (slomo) 2014-01-14 15:05:33 UTC
*** Bug 722184 has been marked as a duplicate of this bug. ***
Comment 3 Reynaldo H. Verdejo Pinochet 2014-01-15 03:27:36 UTC
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.
Comment 4 Alexander Zallesov 2014-01-16 12:59:24 UTC
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.
Comment 5 Tim-Philipp Müller 2014-01-16 13:07:05 UTC
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?)
Comment 6 Alexander Zallesov 2014-01-16 13:40:58 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2014-02-12 09:37:44 UTC
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?
Comment 8 Sebastian Dröge (slomo) 2014-02-12 11:20:22 UTC
Reproduced here now, and looking into it
Comment 9 Sebastian Dröge (slomo) 2014-02-12 11:42:14 UTC
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
Comment 10 Branislav Katreniak 2014-02-19 16:03:43 UTC
*** Bug 724717 has been marked as a duplicate of this bug. ***