[Bug 722185] souptthpsrc: racy "server does not support seeking" error

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=722185
  GStreamer | gst-plugins-good | git

Reynaldo H. Verdejo Pinochet <reynaldo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |reynaldo at opendot.cl

--- Comment #3 from Reynaldo H. Verdejo Pinochet <reynaldo at opendot.cl> 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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.