[NUT-devel] Broadcast sufficiency - my assumptions/reasoning/design for it

[Rich Felker]

[I wrote this earlier but had to leave for work so I didn't finish
sending. Hope there's nothing newer that renders parts of the message
redundant already.]

On Wed, Feb 06, 2008 at 08:23:08PM +0100, Michael Niedermayer wrote:
> > > The preload changes depending on buffer fullness thus is not constant
> > > over a stream.
> > 
> > Is this your whole point? You could have said that a long time ago and
> > saved us a lot of trouble. I think it's entirely unrealistic that
> > someone concerned with low-latency broadcast would have non-constant
> > preload requirements. 
> 
> Constant preload is pretty much the same as saying constant sized frames.
> That is much stricter than CBR.
> You want to limit nut to that? For this i guess the current design is
> sufficient.

There are two perspectives on preload. One is asking the question:
"For this data, what is the minimum amount I can get away with
preloading?" This is a very concrete property of the data to be
broadcast, and like you say, it varies.

The other perspective is a requirements perspective, e.g. "I want
receivers to be able to tune in to my stream and watch it with a
maximum preload delay of 0.2 sec." In this case it does not matter
whether the minimum preload required (in the former sense) fluctuates
between 0.001 sec and 0.2 sec. All that matters is that the maximum
minimum preload required is bounded by 0.2.

> > Or, said differently, if the sender's
> > requirement is that the preload be less than 0.1 second, it should not
> > matter to them whether the receiver is able to get by with only 0.03
> > seconds of preload when seeking to certain points in the stream.
> > Constraints like these are about worst-case.
> 
> well, if the decoder preloads X seconds while needing only 0 seconds then
> it will need X "seconds" more buffer space. -> this effectively doubles
> the needed buffer space.

If instead of "how many seconds to preload" you knew some different
buffer information, I think the problem would go away. I need to think
about it more though and I don't want to give the impression of giving
hasty answers since I've been accused of that already. :(

> > Years and years ago, when talking about AVI and its audio preload
> > feature, 
> 
> avi audio preload is stupid.

Something we still agree on at least..

> > -- if so one could hypothetically even intersperse
> > variable preload recommendations but I really doubt the usefulness of
> > doing so.
> 
> I guess the spec contains a few rules by now forbidding putting info
> anywhere except after the stream headers (which at least contain the huge
> vorbis headers).

Like I just said, repeating the headers frequently is already required
if you're doing broadcast... Maybe this makes NUT sufficiently
unappealing for broadcast that the whole discussion can be dropped,
but for better or worse, I doubt that will happen.

Rich