[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

On Thu, Feb 07, 2008 at 11:41:03PM +0100, Michael Niedermayer wrote:
> 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

Hey Michael,

I've not been around today to reply to your email but just want to let
you know I agree some things might not work as well as I had hoped,
though I'm not sure I agree with your claims about what happens in
this example either. I'd like to look into it more but if it turns out
we cannot meet your requirements for broadcast optimality with my
proposals I'll be willing to see what we can come up with to remedy
that. I have an idea in mind for storing clock sync/buffering data
which would be more flexible and less invasive than the proposals so
far, I think, but I'll wait to write about it til I'm not about to
fall asleep.

I hope you won't hold any grudges over this whole matter as it's been
mostly a series of misunderstandings and miscommunications, not malice.

Rich