[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Wed, Feb 06, 2008 at 12:13:55AM +0100, Michael Niedermayer wrote:
> 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.

Anyway heres an attempt with a buffer size in the header.

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: broadcast3.patch
Type: text/x-patch
Size: 3117 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080206/a1e5950e/attachment.bin>
-------------- 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/a1e5950e/attachment.pgp>