[NUT-devel] Broadcasting nuts [PATCH]

[Måns Rullgård]

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.

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

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

-- 
Måns Rullgård
mans at mansr.com