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

[Michael Niedermayer]

On Wed, Feb 06, 2008 at 08:50:41PM -0500, Rich Felker wrote:
> [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.

This preload limit is also the limit on the buffer. Because at no time
can the buffer be required to contain more,. Seeking to that point after all
would otherwise require that larger amount to be preloaded.
There goes your "end of the tiny mpeg buffers" as in 0.2 seconds you cant
fill a buffer bigger than the mpeg buffers.


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

Yes, preload and transmit_time are interchangeable i think. You can find
one from the other ...


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

No no, mpeg absolutely requires all the headers to be repeated all the time.
And mpeg has much more bloated headers. Low overhead is not a strength of
mpeg ps/ts. Nut does have a huge advantage here, but of course only if it
otherwise can handle broadcast.

[...]
-- 
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/8c1dc69b/attachment.pgp>