[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Thu, Feb 07, 2008 at 03:08:16PM -0500, Rich Felker wrote:
> On Thu, Feb 07, 2008 at 07:51:53PM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 07, 2008 at 11:39:34AM -0500, Rich Felker wrote:
> > > On Thu, Feb 07, 2008 at 02:45:22PM +0100, Michael Niedermayer wrote:
> > > > > > "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. 
> > > > 
> > > > This just scales the numbers, whichever window size you use you cannot 
> > > > transmit data ahead in it at average.
> > > 
> > > The average I'm talking about is over a window 100x larger than any
> > > possible buffer. You've completely misunderstood what I've said all
> > > along.
> > 
> > You claim that you can transmit the 1000 99 byte packets at 100bps
> > at any choosen constant average buffer fullness (=transmit_ts - dts) if the
> > window is sufficiently large. I claim you can ALWAYS scale this so it fails.
> > try 10000 99byte packets at 99.1bps
> > try 100000 99byte packets at 99.01bps
> 
> I choose the window after you choose the scaling. The client buffer
> size depends on the scaling and I can choose the window based on the
> client buffer size.

You are very deeply confused.
The client buffer has never changed, what has changed is the channel
bandwidth, but you can achive the same by changing just the size of the
frames. Your system only works in these examples if you update the
window size depending on the channel bandwidth (and here a x10 for the
window is needed for a 1% change of the bandwidth).

It is extreemly tireing to repeatly proof that your suggested system cannot
handle this example.

I have the feeling you base your emails on the assumtation that your system
is as good as mpeg. Maybe you should not blindly assume this.


> 
> BTW the scaling is pretty meaningless because these 0.01% differences
> are smaller than your clock precision anyway. In any actual real-world

You got the scales wrong. The example got longer and you increas the window
and its VERY MUCH harder to synchronize the clocks in your system. BUT the
clock precission you need has NEVER changed. its just the precission per
window size that has.
If you want a 0.1sec precission that means you NEED a 0.1sec precission
in a 1sec window as well as a 10hour window. If you dont have that, your
decoder freezes as it runs out of data from its 0.2 second preload.


> _broadcast_ stream (where clients can begin receiving at any moment
> and decode with guaranteed small preload delay), the average will be
> constant over small windows, e.g. 10-60 seconds. 


> Your hypothetical
> example above has a HUGE preload delay for clients who begin receiving
> right after the long string of faster-than-realtime transmission
> suddenly goes slower-than-realtime.

Have you lost all sense of logic?
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

To preload these 1000 bytes the time needed is 10second for all these
examples. if thats too long just stop 90% sooner, that is
10000 99byte packets at 99.01bps
1000 99byte packets at 99.1bps
100 99byte packets at 100bps

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.


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/1ad03de2/attachment.pgp>