[gst-devel] a good GStreamer design issue question

[in7y118 at public.uni-hamburg.de]

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

> I don't see aproblem with querying for the latency in either the real
> case or the analogy.  In the analogy, each element is a guy standing at
> the river.  Each of these guys is able to see the next guy and ask them
> something.  While this one guy might not see the end of the river, the
> guy at the end of the river does, and so you just get a bunch of guys
> asking each other to pass along the question of how far it is to the end
> of the river.
>
Unless you find one - or more guys in between who have no clue what 
a "distance" is, so he does not know what to do.
Which brings us back to GStreamer world and to the problems with this approach:
1) elements themselves need not know about latency (they may, but they need 
not) or how to get it (a queue for example has no clue about latency <=> 
buffered data ma´tching since it isn't data specific). Apart from that, you 
have to assume the dumbest possible element. And GStreamer supports very dumb 
elements.
2) querying is broken when it comes to thread boundaries. Since a query will 
always be executed in the querying thread the underlying pipeline may very well 
change the result of the query while the query is still executing.
Therefore queries are only estimates and should be treated as such.
 
> "waiting" is very non-literal here.  The actual implementation doesn't
> really matter.  It could just keep a glist of values to emit in the
> future and compare these to the actual clock at each pass through the
> chain function.
> 
This is a possible way to do it though you would likely miss some signal 
emissions at start/end.

> Ugh.  Besides this being nonintuitive, ugly, and probably wasteful, I
> can't see anything wrong with it.  But, come one.  Two threads just to
> get a level ?
> 
Some things (one of them is everything clock-based) currently is very hard.
And if you want really accurate timebased information/signals, you have to do 
it this way. If you can live with guesstimates, read below :)
I'm putting "rewrite clock system" on the TODO for 1.2, too.

> Haha :) I'm not going to wait until 1.2 just to get a vu meter working
> :)
> 
My current idea would be to emit the signal with the timestamp. The vumeter 
widget can then use g_timeout_add and/or a queue and do the updating itself. 
This gets you around hacks that would be necessary in GStreamer.

Could you file a bug about clocking needing (a rewrite to allow) timebased 
callbacks? Or do we already have something like that?

Benjamin