[gst-devel] clocking

[Christian Fredrik Kalager Schaller]

Hi Benjamin,
Ok, my mail was basically a braindump before I left, so the real time
stuff was just something that popped into my head. What I wanted was
basically this mail you sent, with some explantions on why/how.
Your first mail just made we very worried in regards to 2.6, this mail
restored my peace of mind :)
 
Since no-one objects and Ronald seems to like it I guess you should
commit :)

Christian

On Tue, 2004-01-13 at 14:39, Benjamin Otte wrote:
> On Tue, 13 Jan 2004, Christian Fredrik Kalager Schaller wrote:
> 
> > Hi,
> > Audio/Video sync used to work, what has changed that makes getting it to
> > work with that old (and I assume API compatible way) not possible
> > anymore ?
> >
> With the old stuff, you had problems when
> - you started playing only half of the pipeline, because the moment the
> first element started playing, this was defined as time 0. So if you did
> complex stuff between the first element starting and the elements starting
> that need clocks (autoplugger with debug output activated), you would be
> waaaaaaay off. The "new" pipeline parsing does this...
> - elements seeked to different offsets. Since a clock could only handle
> one discontinuity at all, the second element that seeked didn't do a
> thing. Or (that was the more recent approach) the second discontinuity
> adjusted the clock again.
> - you had multiple pipelines that used the same clock - most likely the
> system clock. (Rb will be the first app to do this when we do delayed
> loading)
> 
> All of this wasn't a pressing issue in 0.6 because we didn't do this and
> so didn't notice.
> 
> > Do a switch to this new element time based stuff change anything else
> > for us?
> > For example will it influence the viability of real-time applications?
> > Does this only influence our video based applications or will RB and
> > friends also need to change to work with this new API?
> >
> No app will need to change a single line of code and work just like
> before (unless it relied on buggy behaviour before). The stuff is ABI and
> API compatible.
> 
> And why do you think this could influence the "viability" of "real-time"
> applications?
> 
> 
> Benjamin
> 
>