KDE4 MM, a view from usability and general applicaiton development

[Ronald S. Bultje]

On Wed, 2004-09-08 at 14:20, Arnold Krille wrote:
> Can GStreamer do 5ms latency? With a desktop running in the back? With a 
> full-featured desktop like kde in the back?
> If the answer is yes, then you probably don't have all the decoding and 
> video-to-sound-synchronising features kde needs...

In addition to what Christian just mailed ("yes"), I'd like to
technically explain why.

GStreamer uses pipeline states, which means that a pipeline can be
switched between multiple states of readiness. Our basic state is NULL
and the elementary state is READY, in between which memory setup and
resource allocation is being done. Between READY and PAUSED, all stream
initialization is done. Between PAUSED and PLAYING, *nothing* is done
except the fact that actual data is now streaming. This means that with
correct pipeline scheduling, the step from PAUSED to PLAYING is as small
as a simple state iteration. Totem Reports a latency of 0,0018 (or maybe
0,018 seconds, I forgot) from PAUSED back to PLAYING.

Synchronization is completely unrelated to this, however. If you try to
go into the discussion that you started using those question, you ought
to know what you're talking about. Latency is a time difference between
an action and a reaction. Synchronization is an effect between two
actions that *are already in motion*. In GStreamer, synchronization is
an implicit part of pipeline data flow, and pipeline data flow is
something that comes *after* pipeline state (and thus latency).
Therefore, synchronization and responsiveness do not interfere.

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>