[gst-devel] totem and osssink? (long)

[Benjamin Otte]

Quoting Martin Soto <soto at informatik.uni-kl.de>:

> In my own elements, I'm printing times in seconds with three decimal
> positions:
> 
>   GST_LOG_OBJECT (sink, "new timestamp: %0.3fs",
>                   (double) timestamp / GST_SECOND);
> 
> it makes a large difference in terms of legibility. It would be nice to
> have a macro or two in gstinfo for that purpose.
> 
Fell free to add GST_TIME_FORMAT and GST_TIME_ARGS to the file that defines 
GstClockTime for that purpose.

> Well, I agree this is an ideal definition of the PAUSED state, being
> consistent with what standard playing devices (CD players and the like)
> do. I don't see it'd be that easy to implement, though. Think of a chain
> based sink going from READY to PAUSED. In order to go to PAUSED it needs
> to receive some material, and probably put it in the hardware buffer
> (you can do that with ALSA: fill the buffer before playing). Problem is,
> it must wait for its chain function to be called before having material
> available. So, the change_state function would have to run concurrently
> with the chain function, which would be weird. 
> 
> Does this make sense or I'm missing something?
> 
You're quite right. Add to this that it does only solve the problem in the 
state changing case, not when you need to replug because of format changes. 
(Which happen at least for DVDs and Oggs)

> This looks easier to implement, needing only some interaction between
> the clock and the scheduler. It doesn't look as nice conceptually,
> though. 
> 
There's more than one scheduler in threaded pipelines, too.
And in gst-launch the sinks are locked at first ;)

> Well, clocks actually work like chronometers right now. They are only
> useful to time intervals. It is actually irrelevant where they start.
> Sharing a clock between pipelines shouldn't be a big deal. However, if
> it stops whenever material fails to flow to an audiosink, for example,
> it may cause trouble.
> 
Yeah, it depends heavily on what you want. The common problem I have is this:
Because of metadata reading and caching in the kernel, every mp3 has its first 
x bytes loaded into memory. The hard disk is spun down. I play such an mp3. 
The first x bytes play perfectly, however after this the hard disk has to 
start rotating to get more data. This causes 5+ seconds of waiting.
Currently it's a nice feature of the audio cocks to wait until this data is 
available.

> > I think on a conceptual level it doesn't matter one bit if a clock uses
> > system time or "time since start of playback" internally; it can be made
> > to work with both, at least in theory.  Using system time just makes it
> > harder to understand IMO, plus to a pipeline the current system time
> > doesn't matter anyway, while time since start of playback has meaning
> > for the system.  Anyway, just MO.
> 
> It really doesn't matter that much. You'd rather not look at the
> absolute value of the clock time, but just regard time differences. On
> the other hand, if the clock does not start in 0, gst_element_get_time
> will start reporting funny values unless you set element time to 0
> explicitly when going to the PAUSE state or something. I don't know if
> there are any provisions for that in gst_element, but I haven't seen
> them so far.
> 
It doesn't matter one bit, as long as nobody resets the clock when someone 
measures an interval, because that interval will be way off then...
And GstElement does adjust its time in its change_state function (as said in 
another mail).

> > There's also the question of what to do when the element moves away from
> > PLAYING.  In theory an element providing this clock is supposed to
> > provide this clock in all states - there is no way for the rest of the
> > system to know currently if a clock cannot function anymore.
> 
> Hmmm, that's a general problem we have with the semantics of clocks. Do
> we really want them to be real time clocks or not? Our typical audio
> clock is not a real time one, in the sense that if the sink doesn't get
> any sound, the clock stops running. IMO, this shouldn't happen, because,
> even it that helps simple pipelines, it may break more complex ones.
> 
audio clocks solve this problem by having a state. They're either "active", 
where they tell the time based on the data flowing - in the playing state, or 
they're "inactive" - every other state, even paused, where they report the 
system time.
And the only thing that should hold for clocks is that they report an 
increasing time. It should not matter if they only increase time aprubtly by 
two minutes every half an hour or if they're synced with a Caesium clock. 
There has been a lot of interest in having a clock that just runs x times as 
fast/slow as the system clock and can be sped up/down.

> > Currently a discont event sends the new time to use as a base time,
> > right ? Here's my idea - have the discont event contain both the new
> > time to use as base time, as well as the ACTUAL clock time at the moment
> > of deciding what base time to use in the discont event.  This maps the
> > old GstClock time to the new base time elements have to use.
> > 
> > When the discont event then reaches the element, the element can query
> > the current clocktime, and add the difference between current time and
> > event's clock time to the base time it has to set.
> >
> > Would this work ?
> 
> Yeah, I guess so. But, please look at my other message in this thread
> for an alternative, anyway. A couple of issues remain. First, all
> elements sending discontinuities will need access to the clock. No big
> deal, but this may be more invasive than just changing the sinks.
> Second, this links the new element base time to the time the discont
> event is sent, which is way before the time the sinks are actually ready
> to play the material following it. In other words, this only worsens the
> problem we previously discussed.
> 
There's a much more important issue. Elements sending discont events (imagine 
filesrc here, or better some chunk-based networked format) don't know anything 
about time. So they cannot say where they seeked to and how much. And don't 
forget queues, the might or might not have buffered data in between that may 
or may not be discarded.
So I guess this wouldn't work at all.

Benjamin