[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Thu, Feb 07, 2008 at 03:52:49PM -0500, Rich Felker wrote:
[...]
> > Have you lost all sense of logic?
> 
> Not last I checked... But if this topic keeps up too much longer maybe
> we all will.

keep checking please! what i cliped away above does not match that
claim.


> 
> > 100000 99byte packets at 99.01bps  will fill the buffer at
> > 0.01bps, it will contain 1000 byte after the 100000 packets
> > 
> > 10000 99byte packets at 99.1bps  will fill the buffer at
> > 0.1bps, it will contain 1000 byte after the 10000 packets
> > 
> > 1000 99byte packets at 100bps  will fill the buffer at
> > 1bps, it will contain 1000 byte after the 1000 packets
> 
> I'm talking about what happens AFTER the switch from
> faster-than-realtime to slower-than-realtime. If there never is a
> switch then the buffer requirements grow without bounds, which is not
> a workable system.

we switch after the max preload limit is reached. That is after the
buffer contains X seconds video.


> 
> > To preload these 1000 bytes the time needed is 10second for all these
> > examples. if thats too long just stop 90% sooner, that is
> 
> It's 9.5-9.9 seconds too long.
> 
> > Nothing changed, you can continue this series in many directions
> > Pick your buffer size, pick your averaging window size, pick your max preload
> > all 3 freely chooseable, the examples still applies.
> 
> No, as long as max preload is tiny, a small averaging window works
> fine. Work out the formal definition of max preload and it becomes
> clear..

I think this might be my last reply before i will continue to work on
nut without you.
This is not a technical discussion but some religious fanatism that
a system would be supperior even though it is repeatly proofen. And id
like to emphasize PROOFEN to be inferrior if not completely non functional.

Heres another random example. This time with max preload of 1 sec and a
window of 1 hour.
I hope thats ok, but we can do this with nano seconds and a million years
if you like.
I also choose 30fps because i know you will pick every last straw as
explanation for why the result is not relevant.

channel bandwidth 3000byte/sec, time base 1/30sec
frame 0      dts 0          size 100    reception time 0
frame 1      dts 1          size 100    reception time 1
...
frame 108000 dts 108000     size 100    reception time 108000
frame 108001 dts 108001     size 200    reception time 108001
frame 108002 dts 108002     size 200    reception time 108003
...
frame 108030 dts 108030     size 200    reception time 108059
frame 108031 dts 108031     size 100    reception time 108061
frame 108032 dts 108032     size 100    reception time 108062
...
frame 216032 dts 216032     size 100    reception time 216062

the max preload in the case above is 1 second, the average is 1 second as
well.
the buffer is empty in the first hour, and contains  3000 bytes
which is 1 second of video in the second hour. The buffer thus has to be
3kb large.
This causes your 1 hour window sync to be off by 1 second and your video and
audio freezing for 1 second as the buffer becomes empty. To avoid this
you can use a twice as big buffer and twice as long preload (of 2 seconds) 
Which is your system needs twice as many resources as MPEG.

BUT! theres a second problem. With a window 1 hour large you cannot
compensate clock drift on smaller scales, that is our example clock
which achives 1min/day precission will be off by 2.5 seconds per hour
thus increasing the needed preload to maybe 3-4 seconds. Mpeg still
is fine with just 1 second.

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- 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/20080207/d288a01c/attachment.pgp>