GNOME Bugzilla – Bug 602419
[basesink] Regression with position reporting
Last modified: 2009-11-19 18:31:30 UTC
Hi, see bug #585969 comment #7. This is caused by this commit http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=f83ea8233bf1661bdab0d4ec6f08169d7c664452 Position reporting between the group switch results in: [...] 0:00:04.913886000 / 0:00:06.965986394 0:00:05.412122000 / 0:00:06.965986394 0:00:01.000000000 / 0:00:05.804988662 0:00:00.420986000 / 0:00:05.804988662 0:00:00.921070000 / 0:00:05.804988662 [...] That weird 1 second is caused by the base time being larger (6965986394) than the clock time (6717317000), resulting in GST_CLOCK_DIFF (base, now) < 0. Then basetime is set to -clocktime and a few times later the position is calulated as follows: *cur = time + gst_guint64_to_gdouble (now - base) * rate;
Oh, and the 1.0 comes from: /* never report more than last seen position */ if (last != -1) *cur = MIN (last, *cur); Last seen position was 1 second in my case
On IRC Jan said, that this could be the right thing: if (GST_CLOCK_DIFF (base, now) < 0) - base = -now; + base = now; Fixes this bug at least.
I think this should fix it: commit 81d3fda6e85181f11e0acb4fcaf60ac49a6e9aac Author: Jan Schmidt <thaytan@noraisin.net> Date: Thu Nov 19 19:00:05 2009 +0100 basesink: Clamp the base time correctly in position reporting When clamping the base time, correctly use 'now', instead of '-now' - the intent is to prevent 'now-base' ever being negative, which would cause a position report outside the segment. Fixes: #602419
Yes, that fixes it