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 781147 - ogv: Seeking OGV over HTTP often hangs
ogv: Seeking OGV over HTTP often hangs
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal blocker
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 781146 (view as bug list)
Depends on:
Reported: 2017-04-10 17:39 UTC by Nicolas Dufresne (ndufresne)
Modified: 2018-11-03 11:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

fix racy seek backwards from http (2.14 KB, patch)
2017-04-24 13:18 UTC, Vincent Penquerc'h
none Details | Review

Description Nicolas Dufresne (ndufresne) 2017-04-10 17:39:59 UTC
Playing this pipeline:


And seeking backward (back arrow), quite often hang. This is observed on git master and 1.10.4. From the back trace, pretty much everything is idles, and soup is waiting for data:

Thread 2 (Thread 0x7fffea168700 (LWP 5402))

  • #0 poll
    at ../sysdeps/unix/syscall-template.S line 84
  • #1 poll
    at /usr/include/bits/poll2.h line 46
  • #2 g_poll
    at gpoll.c line 124
  • #3 g_socket_condition_timed_wait
    at gsocket.c line 3934
  • #4 g_socket_receive_with_timeout
    at gsocket.c line 2806
  • #5 g_input_stream_read
    at ginputstream.c line 198
  • #6 g_tls_connection_gnutls_pull_func
  • #7 _gnutls_stream_read
    at buffers.c line 344
  • #8 _gnutls_read
    at buffers.c line 424
  • #9 _gnutls_io_read_buffered
    at buffers.c line 579
  • #10 recv_headers
    at record.c line 1045
  • #11 _gnutls_recv_in_buffers
    at record.c line 1173
  • #12 _gnutls_recv_int
    at record.c line 1471
  • #13 g_tls_connection_gnutls_read
  • #14 g_tls_input_stream_gnutls_read
  • #15 g_input_stream_read
    at ginputstream.c line 198
  • #16 g_input_stream_read
    at ginputstream.c line 198
  • #17 soup_filter_input_stream_read_until
    at soup-filter-input-stream.c line 226
  • #18 soup_filter_input_stream_read_line
    at soup-filter-input-stream.c line 186
  • #19 read_headers
    at soup-message-io.c line 224
  • #20 io_read
    at soup-message-io.c line 616
  • #21 io_run_until
    at soup-message-io.c line 982
  • #22 soup_message_io_run_until_read
    at soup-message-io.c line 1095
  • #23 soup_session_send
    at soup-session.c line 4425
  • #24 gst_soup_http_src_do_request
  • #25 gst_soup_http_src_create
  • #26 gst_base_src_get_range
    at gstbasesrc.c line 2464
  • #27 gst_base_src_loop
    at gstbasesrc.c line 2740
  • #28 gst_task_func
    at gsttask.c line 334
  • #29 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #30 g_thread_proxy
    at gthread.c line 784
  • #31 start_thread
    at pthread_create.c line 333
  • #32 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 105

There is a ogg warning seen:

0:00:03.087518497  5699 0x7fd1280779e0 WARN                oggdemux gstoggdemux.c:1330:gst_ogg_demux_setup_first_granule:<oggdemux0:src_627cf3f7> Failed to read packets off first page

And some basesrc strangeness:
0:00:03.119029801  5699 0x7fd114118a30 WARN                 basesrc gstbasesrc.c:1633:gst_base_src_perform_seek:<source> duplicate event found 604
0:00:03.254737292  5699 0x7fd114118a30 WARN                 basesrc gstbasesrc.c:1633:gst_base_src_perform_seek:<source> duplicate event found 604
0:00:03.386847072  5699 0x7fd114118a30 WARN                 basesrc gstbasesrc.c:1633:gst_base_src_perform_seek:<source> duplicate event found 604
0:00:03.543654085  5699 0x7fd114118a30 WARN                 basesrc gstbasesrc.c:1633:gst_base_src_perform_seek:<source> duplicate event found 604
Comment 1 Mathieu Duponchelle 2017-04-10 17:45:19 UTC
*** Bug 781146 has been marked as a duplicate of this bug. ***
Comment 2 Vincent Penquerc'h 2017-04-24 13:18:49 UTC
Created attachment 350296 [details] [review]
fix racy seek backwards from http
Comment 3 Sebastian Dröge (slomo) 2017-04-25 13:20:58 UTC
This looks more like a hack then a "trick" :) Can't we properly seek after the initial headers (how do we know they didn't change btw, e.g. with chained oggs), or seek to the headers and parse them properly?

Also why is this a blocker? Did it ever work properly in 1.0? When was it last known to work?
Comment 4 Tim-Philipp Müller 2017-04-25 13:29:30 UTC
Also, what is the race here?

Thanks for looking at this.
Comment 5 Vincent Penquerc'h 2017-04-25 13:36:57 UTC
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,

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.
Comment 6 Edward Hervey 2017-05-18 10:27:16 UTC
Could this be related to the ogg validate tests that constantly timeout/hang ?
Comment 7 Edward Hervey 2017-11-10 09:19:01 UTC
Should be fixed by 770bb07f3059a529a54a3fa3521da641afe25c5e , no ?
Comment 8 Sebastian Dröge (slomo) 2018-02-26 11:09:43 UTC
What should happen with this? Seeking on the original video does not work at all anymore with latest GIT, which seems like an even worse regression (SEEKING query returns false, SEEK event fails)?
Comment 9 GStreamer system administrator 2018-11-03 11:56:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: