Re: [xine-devel] about the clock and the xine interface design

[Miguel F. <mfr...@gm...>]

Hi Michael,

On Wed, 21 Jul 2004 15:14:20 +0200, Michael Roitzsch
<mr...@us...> wrote:
> Here are my ideas about playback speed: I think we have two separate concepts
> of playback speed in xine:
> 
> The first is the current one, which is the speed of the clock the playback is
> synced to. My idea is to solve this completely different in a post-1.0 API.
> What we actually need is a way to create and attach clocks to output ports.
> This should be quite easy since the output ports are already the only xine
> components that need a clock. I think all output ports should by default be
> attached to some xine_t-global default clock, but frontends can attach
> different clocks. Of course, different clocks can have independent speeds
> and, more importantly, outputs with different clocks can be paused
> independently.

agreed.
just remembering to everybody else on xine-devel: these ideas are
*not* meant for xine 1.0.

 
> The second speed is the mapping from logical timestamps to real-life time. We
> need a way to alter this mapping so that a stream's timestamps will be
> translated to physical time in an arbitrary way. My idea would be to
> incorporate this mapping into metronom. For a given PTS-delta, the VPTS-delta
> created by metronom should be larger or smaller by an arbitrary speed factor.
> Of course audio out has to do some adaption by resampling the output, but we
> already have code for that, which should be possible to extend.

this was my thinking too. the problem i realized was the latency to
the new speed to take effect, and to not introduce sync error when
speed changes. how do we handle the already converted VPTSs (waiting
on output fifos) to the new speed?

 
ok, now back to earth ;-)
what do you think about a new speed parameter with finer control?

regards,

Miguel