Re:

On Wed, Feb 06, 2008 at 02:26:01PM -0500, Rich Felker
wrote:
> On Wed, Feb 06, 2008 at 08:02:10PM +0100, Michael
Niedermayer wrote:
> > The point is that this does NOT apply to the
"mpeg design" with transmit_ts
> > as the 11 extra seconds are transmitted during the
1000 low bitrate frames
> > before.
> 
> This means that:
> 
> A. During these 1000 low bitrate frames, each frame was
actually
>    transmitted well-before its decode/presentation
time, so you have a
>    lot of latency.

No the transmitter has access to the whole transmission
unless its a
realtime transmission. 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.


[...]
> Anyway, transmit_ts is not necessary to do what you've
described. It
> works perfectly well in my design, modulo the above
points which apply
> either way. However due to the above, especially C, I
consider this
> very bad broadcast system design.
[...]
> > B. requires 11 seconds instead of 0 seconds
initial preload in the example
> >    (and iam still not sure if clocks could really
be synchronized in all
> >    cases)
> 
> Claiming 0 is simply false. See above.

No its not false, the receiver has a 0 second INITIAL
preload requirement.
At frame 1000 it has a 11 second preload requirementt. And
the average
should be around 5.5 seconds. Thats half of your
suggestion.
You can change all the numbers by a scalar of your choice,
it remains your
design needs 2x the latency on average.


> 
> > And for both A and B the demuxer does not know
what preload it needs to use
> > it has to guess. And thus it will have to guess
higher to be sure its large
> > enough -> more preload and thus latency and
buffering than what mpeg would
> > need.
> 
> I told you, you're totally welcome to add an info
packet with preload
> amount and other bitrate/buffer requirement
information. Now if you
> want to ask whether this info packet is available right
away when the
> receiver starts listening to the broadcast, well that's
another issue
> entirely. You see, all the main/stream headers are
needed, but they
> won't be available until the next time they're repeated
if the
> broadcast is purely unidirectional. As long as you have
this issue,
> it's ridiculous to try to tune NUT for broadcast usage.
One certainly
> could repeat the headers once per preload-interval if
desired, of
> course, or obtain them from some out-of-band source,
but the latter
> would be way outside the scope of NUT...

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

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

When you are offended at any man's fault, turn to yourself
and study your
own failings. Then you will forget your anger. -- Epictetus

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

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

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

On Thu, Feb 07, 2008 at 03:52:49PM -0500, Rich Felker
wrote:
> On Thu, Feb 07, 2008 at 09:37:02PM +0100, Michael
Niedermayer wrote:
> > > 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
> 
> Indeed, sorry, both the buffer size and preload
requirement are
> parameters on which the window size must be based.

If you think so, lets try.
Your buffer size is 6kb, your max preload is 1 second. And
you wouldnt know
either in your system as its not stored anywhere, but lets
assume you do
what is the window size you choose? Yes id like a number so
i can show you
an example where it will fail misserably without you saying
it would have
worked if you could have choosen some other window size.

ahh and fps is 30, and you have a clock accurate to
1min/day

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

When you are offended at any man's fault, turn to yourself
and study your
own failings. Then you will forget your anger. -- Epictetus

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