[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Thu, Feb 07, 2008 at 11:24:31PM +0100, Michael Niedermayer wrote:
[...]
> 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.

Ive made a few tiny mistakes (but as your system breaks down with every
random case, not supprisingly it still does):
the max preload in the case above is 1 second, the average is 0.5 second
the buffer is empty in the second hour, and contains  3000 bytes
which is 1 second of video in the first hour.

Your system will freeze after 1 hour for 0.5 seconds, unless you add this
0.5 seconds preload which would mean 1.5 sec instead of 1.

Also note, that the muxer is not able to achive a constant dts-transmit_ts
at all here

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

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- Måns Rullgård
-------------- 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/99b8d05c/attachment.pgp>