[gstreamer-bugs] [Bug 623540] Add support for querying the stream time and running time
bugzilla at gnome.org
Mon Jul 5 03:03:07 PDT 2010
GStreamer | gstreamer (core) | git
--- Comment #6 from Sebastian Dröge <slomo at circular-chaos.org> 2010-07-05 10:03:02 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > > The current stream time can be get with a position query
> > The position query reports the position (i.e. buffer timestamps) for most
> > elements, not the stream time. Which could be slightly different depending on
> > the applied segment (start and rate) (gst_segment_to_stream_time()).
> That would be a bug then.
So all elements that answer the POSITION query need to keep track of their
segment and return gst_segment_to_stream_time (segment->last_stop) or wherever
they store the last buffer's timestamp (+ duration)? I guess some things have
to be fixed then and this should be made more explicit in the documentation.
> > > and the running_time by taking the clock_time - base_time.
> > That would be the running time of the element that holds the clock, right? But
> > that can be different to the running time inside some element (as calculated by
> > gst_segment_to_running_time() from the buffer timestamp).
> That's true. But you actively need to do something to make elements in a
> pipeline have different base_times (and clocks). Do we really do this and do
> elements in this case need to know about the other 'time domain'?
What about the playbin2 gapless scenario for example? First you play some audio
stream, then you do a gapless switch to a video-only stream, and all without
going through PAUSED/READY again. In that case the base times (start times too?
does it matter?) won't be updated everywhere and a different clock would be
used and the running times in both sinks are different.
Now assume that afterwards we switch to an a/v stream. Now both sinks are
completely different and to synchronize them again you need to know their
different running times and sync them via newsegment events before doing
Is this correct? Or is just some manual base-time adjusting required for
> It sounds like you want to make the POSITION query it more generic so that it
> can return more than just stream_time.
Yes, and make it explicit that the position query always returns stream time.
Extending it might be a bit difficult in 0.10 though because everything that
can answer the query right now only answers the stream time (or something
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs