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 430804 - [PATCH] navseek only seeks (sort-of) partially
[PATCH] navseek only seeks (sort-of) partially
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.5
Other Linux
: Normal normal
: 0.10.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-04-17 21:00 UTC by Mark Nauwelaerts
Modified: 2007-05-26 15:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch implementing additional response to seek nav event (5.17 KB, patch)
2007-04-17 21:12 UTC, Mark Nauwelaerts
none Details | Review

Description Mark Nauwelaerts 2007-04-17 21:00:32 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.
Comment 1 Mark Nauwelaerts 2007-04-17 21:12:23 UTC
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)
Comment 2 Jan Schmidt 2007-04-18 00:32:01 UTC
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.
Comment 3 Mark Nauwelaerts 2007-04-19 20:01:46 UTC
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) ?
Comment 4 Jan Schmidt 2007-04-19 22:29:33 UTC
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)
Comment 5 Wim Taymans 2007-05-26 15:53:35 UTC
closing, should work now.