[gst-devel] Stuff that needs doing...

[zaheer at grid9.net]

On Thu, 8 Mar 2001, Owen Fraser-Green wrote:

> Hi,
> 
> > The idea is that the Bin that does the work uses CORBA internally to make
> > the connection to it's "other half" on the other processor.  The RidgeRun
> > case for this is putting parts of the pipeline on the conjoined DSP.
> > There has to be some means of control communication (state change,
> > argument setting, signals) between the DSP and the main processor, and
> > CORBA seems a good way to do it.
> 
> Right, now I think I see. I think this is analogous to one of the coarse-
> grained distribution ascii art I drew in a post a while back, something 
> like:
> 
>   P===P . . . P===P
> 
> where the elements and, maybe even the bin aren't aware of the network in 
> the middle of the pipeline but something within gstreamer takes care of 
> this detail for the programmer. Do you intend use CORBA for the control 
> signals while handling moving the stream accross the network in gstreamer? 

CORBA for the control signals is probably a good idea.  This is how
PreViking 0.5 is doing it.  You could use RTCP for the control also...this
would probably be easier to write and quicker..

The media should go with RTP.  Thats what its for, and is a very elegant
protocol that keeps things simple.
 > 
> > > 5) Simltaneous events e.g. flush arriving on one pad at exactly the same
> > > time as an EOS. Or a seek coming the other way! Urghh!
> > Shouldn't be a problem, because simultaneous events can't actually happen.
> > Remember that everything in a given process context is synchronous.  
> 
> I realise that events can't normally happen physically simultaneously but 
> surely they can logically. What I mean is, surely it's conceivable that one 
> event arrives scheduled for timestamp X and another arrives, albeit 
> slightly after also with timestamp X.
> 
> > > 3) An event handling function within the element is magically called by
> > > something outside when an event occurs.
> > Of those, 3) is the way everything else is done, so.... <g>
> <snip>
> > Remember though that everything is in the same process context, so nothing
> > happens at the same time.  If an event callback fires before the next
> > buffer comes in, that's exactly what has happened.
> 
> Yes, but it's because it's happen synchronously that I can't see how a 
> chain loop can be interrupted at the correct time while processing a 
> buffer. Or is it that events can only occur at the end of each buffer? In 
> which case ignore most of previous post :)
> 
> Regards,
> Owen

Regards

Zaheer