GNOME Bugzilla – Bug 430804
[PATCH] navseek only seeks (sort-of) partially
Last modified: 2007-05-26 15:53:35 UTC
navseek does properly perform a "seek" in response to navigation events, but it does so (e.g.) by only sending a seek event. Since this is not the "full" seek protocol as performed by a pipeline (involving some more steps), the effect is not (as user-friendly as) what one might hope to expect from a "seek", particularly when seeking backwards.
Created attachment 86530 [details] [review] Patch implementing additional response to seek nav event * [optionally] use top-level pipeline element to perform a seek * old or new behaviour can be toggled by a particular key-press * also segment-seeking has been given an alternative, though it may be a bit tricky to send seek-event from within streaming thread anyway (and even more so when sinks are temporarily paused as part of the process)
It's only flushing seeks you can't send from within the streaming thread, so that should be fine... but from the 0.10.3 (next) version of GStreamer core, it's unnecessary to pause the pipeline anyway, because sinks can request new preroll asynchronously - all the pipeline stuff that used to be triggered by pausing and unpausing the pipeline happens automatically.
I am not quite sure if the above means to say that navseek will turn out OK by itself, due to the (impending) changes in core. In any event, to elaborate; I think it is particularly about the base_time manipulation. In the present (released) situation, the following happens: let the pipeline play until (e.g.) position 30s, let then navseek perform a 10s offset forward seek, then playing will continue at (about) 1m10s (= 40s + 30s running_time), due to sync inspired dropping. Similar and then even weirder looking effects happen upon backward seek or subsequent seeks. This is not a "seek" one would expect, and in such a form not a comfortable potential debug help. With the "full" pipeline manipulation, navseek moves about as (normally) desired (definitely for the non-segment/loop seek, which happens in a separate thread anyway). So, will all of this (including base_time and related effects) then happen automaticaly (somehow) ?
Yeah, in the newer core, the flush events caused by sending the seek upstream will result in the sinks being given a new basetime, so it should Just Work (and does - I'm using it for DVD playback)
closing, should work now.