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

[Rich Felker]

On Wed, Feb 06, 2008 at 07:22:14PM +0100, Michael Niedermayer wrote:
> On Wed, Feb 06, 2008 at 12:43:21PM -0500, Rich Felker wrote:
> > On Wed, Feb 06, 2008 at 12:40:53PM -0500, Rich Felker wrote:
> > > > Also this would only solve ONE single problem brought up. Your design
> > > > still leaves the preload time up to pure luck.
> > > 
> > > If you really need to know a minimum preload time, put it in a
> > > protocol header or in the spec for the broadcast constraints.
> > 
> > An info packet field for bitrate information, including minimum
> > preload, would be totally acceptable too if you like.
> 
> 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. 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.

Years and years ago, when talking about AVI and its audio preload
feature, I thought we agreed to ignore highly device-dependent
buffering details in the interest of making a container that is clean
and simple. If there's a need to know the amount of preload required
for streaming, a single global value in an info packet should be
sufficient. IIRC info is still allowed to change mid-stream too (or
was that removed?) -- if so one could hypothetically even intersperse
variable preload recommendations but I really doubt the usefulness of
doing so.

Rich