[gst-devel] clocking

[Thomas Vander Stichele]

On Thu, 2004-02-12 at 16:30, in7y118 at public.uni-hamburg.de wrote:
> Quoting Thomas Vander Stichele <thomas at apestaart.org>:
> 
> > After going over the old and new clocking system, and trying to figure
> > out what you think was broken, I'm pretty much lost.  Basically, if
> > you're going to claim it was "extremely broken" I think you should back
> > that up with an explanation :) FWIW you seem to call things either
> > perfect or broken.
> > 
> 1) The old system reset the time of the clock when a toplevel pipeline went 
> from PAUSED to PLAYING.
(I'm assuming you meant PAUSED to READY here - at least that's how I
remember and how it looks to be from looking at the code).  To me this
seems correct behaviour.

>  If you have multiple toplevel pipelines using the same 
> clock, you have a problem. (It should be possible to reproduce by using 
> esdsink and trying to play a file while loading your library - I haven't tried 
> that).

Why would you need multiple toplevel pipelines *with the same clock* ? A
clock is connected to a pipeline.  It is possible to set the same clock
as for one pipeline on a different pipeline, but this should only be
done when there is good reason to do so - for example, to sink two
output devices to the same clock even though they're playing something
different.
In general, I don't see the need for any current application to have
this, can you give an example ?

> 2) The old system reset the time of the clock when a toplevel pipeline went 
> from PAUSED to PLAYING. 
(I'm assuming here you mean "the old system unpauses the clock when
going from PAUSED TO PLAYING).

> This means that when the clocking elements go from 
> PAUSED to PLAYING (which can be quite a bit later when you use gst-launch with 
> SOMETIMES pads) they might discard the first part of your data as being late.

Yes, and this is indeed a bug.  However, IMO it can be fixed in a better
way.  In the long run, I really think we should re-evaluate states and
state changes.  After discussing with people and thinking about it a
little more, I think in general that
- a change between PLAYING -> PAUSED -> PLAYING should be inexpensive
- READY -> PAUSED should prepare EVERYTHING for data flow, up to the
moment where it hands the first buffer to rendering elements (output
sinks), so that they are ready for instantaneous data flow.  This is up
to the scheduler to see this.
- data is allowed to flow in the PAUSED state to handle negotation and
get the first buffer of data to the output sinks.
- this would mean going from PAUSED to PLAYING really is just a matter
of setting the clock to play and getting data to flow, and having the
clock start running at the same time when data is being rendered.

Of course, this is not a change to make right now.  However, for the
clocking stuff, the solution to me seems rather simple - the clock
should only start running when the all the elements in the pipeline that
need to go to PLAYING, are in the PLAYING state.  To do this the
scheduler can keep track of a count of elements that are in PLAYING, and
when all elements needing to go to PLAYING are in fact PLAYING, it can
start the clock.  For going from PLAYING to PAUSED, the reverse could be
done; the clock can be stopped immediately.

This would already make sure we have "correct clock behaviour" before we
can re-evaluate how it ideally should work.  How does that sound ?


> and after that allowed no more discontinuity to happen, so it wasn't bad if to 
> sinks called handle_discont. One perversity with this is that to get around 
> that limitation, some elements deactivated and then activated the clock before 
> making it handle disconts, so the discont worked.

I don't think the semantics for discont were clearly defined.  It is
something that would need to be reviewed anyway.  But your explanation
of it is a bit vague, could you elaborate on it so I can follow ?

The real problem, I think, is 2) - the clock would already be running
before data was actually flowing, and thus the sinks drop data because
it is too late.  This is fixable in the old system.

I'm a bit worried because we changed behaviour, introducing new bugs
(like, pause playback after x secs, then press play, and have to wait
for x secs for playback to resume), and deprecating API that is good API
to have, and that some people were relying on.  I'm pretty sure we can
fix the bugs of the old system without needing to switch over the
internals completely.

If the switchover was to internals that are more mature and developed,
I'd be fine with it.  But right now the switchover is such that the only
thing we can do with some of the more useful clocking API is deprecate
it, and that doesn't really seem like a good change to make, if we're
going to have to redo it in 0.9 anyway.

> The old way doesn't make a lot of sense. ;)
> Just the fact that there's only one time inside a pipeline and the fact that 
> time may be adjusted is bad enough for me.

It makes sense to me to have only one clock for each pipeline - the
"time" is basically "the playing/process time (since the last reset of
the pipeline) of a rendering sink inside the pipeline".  It means
exactly that, and, it's clearly defined.  In cases where you only have
one rendering sink, this makes it easy.  In cases where you have more
than one, one rendering sink uses the clock of the other through the
pipeline, so they end up synchronized.

As for time being adjustable - like I said, I'm not sure DISCONT was
clearly defined.  To me it seems like seeking shouldn't be causing a
clock discont, for example.

How about this idea - we start discussing actual pipelines and
scenarios, so we get an idea of what we want to achieve with clocking
and how it should work ? It would make it possible for us to discuss
this using the same ideas/concepts.  I'll reread your clocking doc
again.

As for the actual clocking stuff, what precisely do you think is
unsolvable in the old system ? And what are your plans on the deprecated
API that was useful to others, and the bugs that have been introduced
because of the changed clocking ?

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If I say goodbye to love
will it go away ?
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/