[Bug 781147] ogv: Seeking OGV over HTTP often hangs

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=781147

--- Comment #5 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> ---
I suppose it would not work with chained oggs.
I don't remember now why parsing the headers would fail. I think it'd cause a
reconfiguration, somehow. No idea whrther this worked before, or when it did.

The race turns out to be an interaction with souphttpsrc: if seeking back to 0,
in some cases the souphttpsrc will not reset its current known read position:

  if (src->msg && src->request_position > 0) {
    gst_soup_http_src_add_range_header (src, src->request_position,
        src->stop_position);

request_position is 0, so no range header is added. The read_position is reset
in _add_range_header.

Then it gets to gst_soup_http_src_create. the test "if (src->request_position
!= src->read_position)" will fail, and it will kill its input stream,
recreating it. This will cause it to send the same data to oggdemux forever
(the start of the stream from byte 1). oggdemux wouldn't like it, and wait
forever for more.

If you seek back shortly after start, it will always deadlock. If you wait a
second or two, it will sometimes do and sometimes not, since the bisection
algorithm will yield different values depending on where you seek from.

Now, what's not clear to me, however, is why *sometimes* it works if you seek
to 0.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.