[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Wed, Feb 06, 2008 at 12:31:06PM -0500, Rich Felker wrote:
> On Wed, Feb 06, 2008 at 05:44:16PM +0100, Michael Niedermayer wrote:
> > > Mark the buffer with actual receive times, according to the local
> > > clock, and correlate them with the timestamps in the NUT stream,
> > > smoothing out any timing adjustments over a long interval that's still
> > > an order of magnitude away from the length needed for drift to become
> > > a problem. 
> > 
> > Ill try again with an even simpler example to make it harder to miss the
> > problem. Eventually you will have a problem to ignore it and pretent
> > some disconnected solution might work
> > 
> > lets assume 1 frame/sec video, and 100byte/sec channel rate
> > Frame 0   dts   0 99byte received at 0
> > Frame 1   dts   1 99byte received at 0.99
> > Frame 2   dts   2 99byte received at 1.98
> > ...
> > Frame 1000 dts 1000 99bytereceived at 990
> > 
> > vs.
> > 
> > 99byte/sec channel rate
> > Frame 0   dts   0 99byte received at 1
> > Frame 1   dts   1 99byte received at 2
> > Frame 2   dts   2 99byte received at 3
> > ...
> > Frame 1000 dts 1000 99byte received at 1000
> > 
> > The above 2 are with atomic clock based transmitters and receivers. 
> > Now assume the clocks drift how are you going to detect let alone compensate
> > for this? Either of the 2 outputs could have come from the other stream if the
> > clock drifts in the right direction.
> 
> A clock this bad would drift by 1/4 an hour per day. I doubt anyone
> would buy such a clock...

Of course one can repeat that with 999/1000 or a smaller drift. It doesnt
change anything


> 
> With that said, let's analyze the situation. In your 100 byte/sec
> scenario, the data is being transmitted too fast by the sender. If
> clocks are in perfect sync, the buffer will grow unboundedly on the
> receiving side. 

Let me show you the next few lines of my first example, it was so simple
that one easily can push the problem around.
Frame 0   dts   0 99byte received at 0
Frame 1   dts   1 99byte received at 0.99
Frame 2   dts   2 99byte received at 1.98
...
Frame 1000 dts 1000 99bytereceived at 990
Frame 1001 dts 1001 200byte received at 990.99
Frame 1002 dts 1002 200byte received at 992.99
Frame 1003 dts 1003 200byte received at 994.99
Frame 1004 dts 1004 200byte received at 996.99
Frame 1005 dts 1005 200byte received at 998.99
Frame 1006 dts 1006 200byte received at 1000.99
Frame 1007 dts 1007 200byte received at 1002.99
Frame 1008 dts 1008 200byte received at 1004.99
Frame 1009 dts 1009 200byte received at 1006.99
Frame 1010 dts 1010 200byte received at 1008.99
Frame 1011 dts 1011 200byte received at 1010.99
Frame 1012 dts 1012  99byte received at 1011.98



> 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.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080206/104060a0/attachment.pgp>