[gst-devel] a good GStreamer design issue question

[Thomas Vander Stichele]

On Tue, 2003-09-23 at 17:10, in7y118 at public.uni-hamburg.de wrote:

> Second, querying the time it will take to output the data is not possible. IMO 
> it shouldn't be possible - at least not for an element. An element is just one 
> position inside a stream, it has no knowledge about what happens upstream or 
> downstream. (I imagine it like this: An elemeent is like some guy standing at a 
> river. He can look upriver and downriver and see what water comes and where the 
> water goes and can even do stuff to the water. But he will never know what 
> happens after the next turn in the river, let alone at the end of the river.)

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.


> > a) one possible way to solve this would be some trickery in having the
> > level plugin emit the signal only at the right moment by telling the
> > clock to wait on the timestamp of the buffer; don't know if that would
> > work, though
> >
> This is not really what a filter could do, because that might cause problems 
> downstream. GStreamer only allows one source and one sink per thread to block 
> (which is why you need threads for proper A/V sync.)

"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.

> > b) another way would be some way to query the downstream delta; ie, try
> > to figure out how much time it will take before playback
> >
> I wrote above why I think this is not a very good idea.

Well, yes and no.  It seems to run contrary to your beliefs, but you
didn't really say why it does so or why this is not a good idea.

> No. An audio sink is an audio sink and only an audio sink. And an audio sink 
> outputs audio to the sound output. If that requires computing a level, then it 
> may very well do that. If it doesn't require that, then it's the wrong element 
> for the job.
> Don't bloat the elements. Let every element only do one well defined job.

Doing it in something outside of the elements is exactly what I wanted
to do to avoid bloat.  I do not really care about how this is
implemented, but it should be easily possible.


> Ronald's idea sounds quite nice to me already, though my first idea was a bit 
> different (*fetches ascii art stick*):
>            ---> { queue --> osssink }
>           /
> --> level
>           \
>            ---> { queue --> fakesink }
> level would have an output in a new level-based mimetype - people may even want 
> to use that later on for a normalization element or feed its output to gst-sci 
> or whatever.

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 ?

> This makes sense because the level information is a new data stream really.

It depends.  It doesn't need to be.  Right now I reworked level some
more and it signals nicely, and I think that's all it needs.


> The thing that might sound a little complex now is the fact that we add a lot 
> of elements to the pipeline. This should not be a problem though. I expect to 
> see pipelines with 1000 elements in the future (Cubase for GStreamer with 
> included gst-based synthesizers), so 2 more elements shouldn't be a big thing.

Give it a shot :) I don't think it handles more than 8 or 16 elements
nicely.  I keep running into serious problems whenever I try.

> The only problem is that every element waiting on the clock needs its own 
> thread. This is a bug I'd mark 1.0 or 1.2 :)

Haha :) I'm not going to wait until 1.2 just to get a vu meter working
:)

Thomas

Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
I feel like I'm at something you always say you need more time
Well I'll stay right here and I'll wait for good
until I find a love worth mine
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/