[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

On Wed, Feb 06, 2008 at 06:46:08PM +0100, Michael Niedermayer wrote:
> > On the other hand, if the sender is doing the correct
> > thing and only sending at 99 bytes/sec, but the receiver sees it as
> > 100 bytes/sec due to clock drift, there is no problem. 
> 
> Ohh there is a problem, your receiver requirement for initial preload
> changed from 0 seconds to 11 seconds. Having 11 seconds delay after
> every seek is something which ill leave to you to explain to the user.
> Also as you dont want to store any hints on preload in the file the
> receiver has to guess how much it has to preload.

Absolutely not. The preload requirement is not changed. No one cares
that the presentation time of a frame is off by 0.01 second (1%). In
fact in real world applications it will be more like 0.1% or smaller,
and with real world framerates that's less than 0.0001 sec.

The issue is not about achieving some "perfect" timing with respect to
matching a remote clock (which is fundamentally impossible due to
relativity anyway :) but to correct long-term drift that will lead to
buffer overflow or underflow if left unaddressed. The system I have
explained does that just fine and does not increase preload or
latency.

Rich