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

[Michael Niedermayer]

On Wed, Feb 06, 2008 at 01:36:56PM -0500, Rich Felker wrote:
> 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. 

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.


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


> 
> Years and years ago, when talking about AVI and its audio preload
> feature, 

avi audio preload is stupid.


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

the transmit_ts are a better choice, also if you seriously want device
indpendance. It might be possible to specify the minimum needed
preload vs bandwidth curve somehow on each syncpoint. This would not
add any dependance on the actually used bitrate or buffers.
But allow a demuxer (which approximately knows the bandwidth) to
choose the ideal preload, or even download the whole file if the bandwidth
is too low. It also might be possible to synchronize the clocks based
on such preload/bandwidth data.


> IIRC info is still allowed to change mid-stream too (or
> was that removed?)

Removed after your flames IIRC. Its also a point which will cause problems
as soon as anyone wants to use info for anything realtime.


> -- 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).
I stoped counting, the how manyth case is this where your strict info
design causes problems?

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20080206/d45a6097/attachment.pgp>