GNOME Bugzilla – Bug 781147
ogv: Seeking OGV over HTTP often hangs
Last modified: 2018-11-03 11:56:26 UTC
Playing this pipeline: gst-play-1.0 http://upload.wikimedia.org/wikipedia/commons/a/a4/Xacti-AC8EX-Sample_video-001.ogv 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:
+ Trace 237350
Thread 2 (Thread 0x7fffea168700 (LWP 5402))
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
*** Bug 781146 has been marked as a duplicate of this bug. ***
Created attachment 350296 [details] [review] fix racy seek backwards from http
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?
Also, what is the race here? Thanks for looking at this.
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.
Could this be related to the ogg validate tests that constantly timeout/hang ?
Should be fixed by 770bb07f3059a529a54a3fa3521da641afe25c5e , no ?
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)?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org'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: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/351.