[gst-devel] clocking

Benjamin Otte in7y118 at public.uni-hamburg.de
Tue Jan 13 05:41:04 CET 2004


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





More information about the gstreamer-devel mailing list