Re:

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

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. 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. The
measured
mean difference between dts and receipt_time will be 0.45
for the
first 10 frame window, 1.45 for the second 10 frame window,
etc. This
drift in mean serves to adjust the receiver's clock.

In the example here it seems like very small windows and
very quick
adjustments would be necessary, but that's only because of
the
ridiculousness of the magnitude of the clock's error in your
example.
Normal clocks do not drift by 15 minutes per day.

Rich
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Wed, Feb 06, 2008 at 12:31:06PM -0500, Rich Felker
wrote:
> mean difference between dts and receipt_time will be
0.45 for the
> first 10 frame window, 1.45 for the second 10 frame
window, etc. This

Obviously I forgot to divide by 10 in writing the means.
 They
should be 0.045 and 0.145 respectively, of course.

Rich
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

No, but people buy various embeded devices to watch videos
and their clocks
are supposed to be cheap. And while i dont think they would
be off by
15min/day i doubt you can expect more than 1min/day accuracy
from them.

Also my HP notebook is 1min off per week or so.

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

Freedom in capitalist society always remains about the same
as it was in
ancient Greek republics: Freedom for slave owners. --
Vladimir Lenin

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Thu, Feb 07, 2008 at 03:17:02AM +0100, Michael
Niedermayer wrote:
> > > It really is a 0 vs. 11 second difference
for
> > > the receier after you switch it on/or tune to
the channel at the start.
> > 
> > You'll have to clarify perhaps with an example
because you're not
> > making sense to me.
> 
> Iam not talking about live streams, just a normal tv
movie being broadcast
> for example. Here the 99byte per frame can be
transmitted faster than
> realtime thus when the high bitrate 200byte per frames
are reached. They are
> already available to the decoder a few seconds before
they are needed.
> 
> Of course if you dont start watching at the start but
at some other point then
> some larger preload might be needed.

For all practical purposes, the viewer ALWAYS starts
watching at some
other point than the "beginning" which hardly even
exists except at
some distant point in history. _Broadcast_ means a
unidirectional
where all 'clients' receive the same thing, whatever is
currently 'on
the air'.

Thus, I see the whole issue as unworthy of consideration.
For genuine
broadcast purposes, the buffering constraints must be such
that
clients can pick up and immediately start playing at any
point in the
broadcast. Transmitting low-bitrate parts
faster-than-realtime, aside
from over very short intervals, has no practical purpose in
such an
application because it will mean long intervals of time
during which
it's impossible to start watching the broadcast.

> "your design B." here was the case that the
transmitter was not allowed to
> transmit the first 1000 99bte frames at 100byte/sec but
was limited to 
> 99bytes/sec. This causes a larger preload requirement
at the start. And

2 issues here:

1. I never said you're not allowed to transmit the first
1000 99-byte
frames at 100 bytes/sec, only that the average difference
between dts
and transmit time over VERY LARGE windows needs to be
constant. Here,
very large means much larger than the buffer size but much
smaller
than the time scale on which the clock error grows too
large. Unless
your buffering (and worst-case preload time) is extremely
huge or your
clock is extremely bad, there will always be a HUGE (several
orders of
magnitude) margin of choice for the window size between
these two
bounds.

2. Even if you want to compare the version that cannot
transmit
anything faster-than-realtime (which is more restrictive
than my
proposal) to the version that can, the worst-case preload
requirement
is always the same. This stream is entirely unusable for
broadcast
purposes due to that fact.

> without the transmission limit my proof of the
impossibility to sync clocks
> would apply.
> And honestly i dont think the clocks can be
synchronized reliably even with
> some simple limits.

My proof of the ability to sync clocks always works as long
as you
treat the window of mean-difference sampling as being
significantly
larger than the receive buffer. Do I need to write it out
formally?

> > > The main/stream headers are just needed once,
if i switch channels around,
> > > i already have them after a few minutes for
all channels. And wont want to
> > > wait for them ...
> > 
> > After a few minutes? 
> 
> You missunderstood me. I meant if i cycle through all
channels trying to find
> something not being total trash (which might take a
minute). I do afterwards
> have all headers and wouldnt want to wait at all for
them. That is i would
> benefit from more frequent preoad/transmit_ts than just
after the headers.

I think this argument is weak. Any broadcast scenario where
there's a
significant delay the first time you tune to a new channel
has
essentially zero chance of being market-viable. The headers
will have
to be repeated at least once every 2-3 seconds and probably
2-3 times
per second...

Rich
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel