[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Tue, Feb 05, 2008 at 10:42:57PM +0100, Nico Sabbi wrote:
[...]
> > >  Index tags:
> > >  -----------
> > >  
> > > @@ -978,6 +984,42 @@
> > >  
> > >  Demuxers SHOULD NOT search the whole file for info packets.
> > >  
> > > +
> > > +Broadcast buffering model:
> > > +--------------------------
> > > +Nut files can be broadcast. Such specific nut files must be encoded and
> > > +muxed so as to not exceed the decoder side buffering or available bandwidth.
> > > +This spec does not provide any restrictions on the decoder buffers or
> > > +bandwidth. Nor does it mandate that the channel be transmitting at a constant
> > > +rate.
> > > +For sake of simplicity a zero latency channel is assumed. Note, due to the
> > > +lack of a back channel any constant latency channel is indistingiushable from
> > > +a zero latency channel.
> > 
> > FYI, the MPEG spec makes the same simplification.
> 
> the buffer sizes should be indicated in the headers, or how can the demuxer allocate
> them without assuming "the ram is the limit" ? Also, having fixed-size buffers
> helps to avoid realloc()s

A software demuxer must be able to allocate whatever buffers it needs anyway,
as only broadcast mode nuts would have such values. Also due to security they
would need to deal with running out of buffer space anyway. And hardware
demuxers have fixed buffers thus again not needing their sizes in the stream.


[...]
> > > +As data is received (between the 2 transmit_ts of the 2 enclosing syncpoints)
> > > +it is inserted into a FIFO buffer. The spec does not mandate a single or
> > > +multiple FIFOs,. Nor that demuxing is done before or after the FIFO. Just
> > > +that a valid nut broadcast never causes an overflow nor underflow in the
> > > +target receiver/demuxer/decoder.
> > > +
> > > +Frames are instantaneosly removed from the fifo at their dts and inserted
> > > +into the decoder.
> > 
> > These paragraphs are not really necessary.  If you want to provide a
> > timing/buffering model akin to that in the MPEG spec, you have to be
> > much more precise.
> 
> better remove this paragraph altogether than over-specifying what is obvious

I dont think this is obvious to people who havent had contact with mpeg.

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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/4877da4c/attachment.pgp>