[gst-devel] clocking

in7y118 at public.uni-hamburg.de in7y118 at public.uni-hamburg.de
Thu Feb 5 10:08:43 CET 2004


The reason why everything clocking related is in such a bad state is because 
clocking was extremely broken even in 0.6 and I only fund out at the beginning 
of January when we were supposed to be API stable.
Getting this fixed correctly with thinking about how it should be done, 
implementing and testing it would have taken until February and would have 
involved API changes.

So from my point of view clocking is as broken as threading: It works most of 
the time, but don't dig too deep or it will blow up.


Quoting Thomas Vander Stichele <thomas at apestaart.org>:

> I have the same mixed feelings.  I hope that in the future we can stop
> deprecating/tearing apart old stuff without a good explanation of what
> was wrong/unfixable with the old design, and a good design for the
> future so everyone can help in validating and fixing.
> 
You are all free to dig through the code and figure out how it works. It's 
open source for a reason. After that we can discuss design decisions. I'm not 
gonna babysit developers through our code though.

> Some important things that could be clocking-related (but nobody seems
> to be able to tell) are still not fixed (mpeg playback, next/next in the
> player, ...).
>
next/next should be fixed.

> We should decide to either revert to the old situation (the enemy we
> know) or make sure these bugs get fixed ASAP and we have a decent design
> for it that more than one person can understand.
> 
Everybody can understand it. It's just that noone ever takes the time to read 
the code. And you don't want to revert to the old system, trust me. You'd have 
to fix pipeline parsing in that case...

> > BTW: I consider either the deprecation of id_wait_async or the lack of
> > gst_clock_wait_async to be a 0.8 blocker.
> 
> Agreed.
> 
You're free to undeprecate it. It should still work. I deprecated it because I 
don't want people tinkering around with a broken clocking system.
FWIW, async waiting was always optional for clocks to implement. Just pretend 
no clock implements it.

Benjamin




More information about the gstreamer-devel mailing list