[NUT-devel] Broadcasting nuts [PATCH]

[Nico Sabbi]

Il Tuesday 05 February 2008 22:41:49 Måns Rullgård ha scritto:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > Hi
> >
> > Attached patch should make broadcast of single program nuts possible.
> > Its the minimal/least restrictive solution i found.
> >
> > Comments welcome, especially from mans/nico, others who know mpeg-ps/ts.
> >
> > Index: nut.txt
> > ===================================================================
> > --- nut.txt	(revision 588)
> > +++ nut.txt	(working copy)
> > @@ -412,6 +412,7 @@
> >  syncpoint:
> >      global_key_pts                      t
> >      back_ptr_div16                      v
> > +    transmit_ts                         t
> >      reserved_bytes
> 
> You could make this field optional.

agree. A muxer not wanting (or not knowing how )  to transmit transmit_ts should
be allowed to skip it rather than inserting all 0s

> 
> >              Complete definition:
> > @@ -775,6 +776,11 @@
> >      global_key_pts MUST be bigger or equal to dts of all past frames across
> >      all streams, and smaller or equal to pts of all future frames.
> >  
> > +transmit_ts (t)
> > +    The timestamp at which the first bit of the syncpoint is transmitted.
> > +    MUST be less than or equal to all following dts.
> > +    See broadcast buffering model.
> 
> This is not strict enough.  The transmit_ts must be less than the DTS
> of any not completely received frame.
> 
> >  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

> 
> > +The time at which a syncpoint is transmitted as well as received is stored in
> > +the transmit_ts of it. The receiver/demuxer/decoder can use these timestamps
> > +to synchronize its clock. The (possibly variable) rate at which the following
> > +bits/bytes are transmitted depends on the hardware and is outside this spec.
> > +Except that, the last bit before the next syncpoint MUST be transmitted before
> > +the following syncpoint, and the target reciver/demuxer/decoder must be
> > +capable of handling it without errors.
> 
> I don't understand that last sentence.
> 
> > +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

> 
> > +If the latency of the channel is non constant, the reciver/demuxer must
> > +use a FIFO or other method to compensate for the variations.
> 
> This is also mostly irrelevant to the spec.
> 
> > +A nut demuxer in a non broadcast model MUST NOT fail due to transmit_ts
> > +being set to valid but insane values (like all 0, or all equal to the
> > +next dts).
> 
> I find "valid but insane" rather vague terminology for a spec.
>