GNOME Bugzilla – Bug 623540
Add support for querying the stream time and running time
Last modified: 2012-09-28 09:37:39 UTC
Hi, it'd be nice if we had a way to query the current stream time and running time from some element. We could either add two new queries for this or a single one (QUERY_TYPE_TIME) with two different flags. I'd vote for two different queries, any other oppinions? I'd like to implement this ASAP
Wouldn't this need (or be complementary to) wim's proposal to store segments (via GstSegment) at the pad level for 0.11 ? The default would then just be to query the current stream/running time of the sink/src pad.
That would be bug #601582 then btw and could be fixed for 0.10 already. Well, if the pads store the segments and keep track of timestamps and everything it could be implemented at the pad level. Including the current position query. Until then we could implement it as another query type that can be answered by elements that keep track of their segments. After some more thinking I would implement it as a single query, GST_QUERY_TYPE_TIMES, which would query both times at once. If something can know the stream time it can also know the running time. (Use case for this is btw playbin2's gapless playback. It needs to get the running times of the sinks when gapless switching between tracks.)
(In reply to comment #0) > Hi, > it'd be nice if we had a way to query the current stream time and running time > from some element. The current stream time can be get with a position query and the running_time by taking the clock_time - base_time. What more is needed here?
(In reply to comment #3) > (In reply to comment #0) > > Hi, > > it'd be nice if we had a way to query the current stream time and running time > > from some element. > > 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()). > 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).
(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. > > > 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'? It sounds like you want to make the POSITION query it more generic so that it can return more than just stream_time.
(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 anything else. Is this correct? Or is just some manual base-time adjusting required for playbin2? > 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 wrong)
Obsolete in 0.11 ?
I think this is obsolete. Please re-open if not.