[gst-devel] clocking

[in7y118 at public.uni-hamburg.de]

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. 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).
2) The old system reset the time of the clock when a toplevel pipeline went 
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.
3) The old system could not handle multiple discontinuity events. You had 
gst_clock_handle_discont and that set the time according to the discont event 
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.

These are three things I remeber from the top of my head.

> The clocking system already passed the basic test Christian layed out in
> 0.6, and it is really hard to evaluate why your start of a rewrite is
> better at all.  After discussing it a little with Wim yesterday I really
> don't see what problem was unsolvable in the 0.6 clocking system, so I
> have the feeling doing such fundamental changes so late in the cycle was
> wrong and we should revert and figure out how to properly do clocking.
> 
If you come up with a better solution, go ahead. :)
The problem with the 0.6 clocking systemis its failure to seperate system 
time, stream time and synchronization and trying to do all at once.

> As Andy said, there were people who knew and used the old system, and it
> seemed to work fine for them.  Also, conceptually, the old system makes
> a lot of sense.  I'm not saying the new one does not, I'm saying I have
> no way of telling if it makes more sense and if it was right to make the
> changes.
>
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.

Benjamin