[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

On Tue, Feb 05, 2008 at 09:31:14PM +0100, Michael Niedermayer wrote:
> Hi
> 
> Attached patch should make broadcast of single program nuts possible.

It's already possible. The claim that any of these things are needed
is a fallacy.

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

Waste of space and does not do anything useful.

> +
> +Broadcast buffering model:
> +--------------------------
> +Nut files can be broadcast. Such specific nut files must be encoded and

There are not different types of NUT files. NUT is device-independent
and the muxing MUST NOT DIFFER depending on the intended use. This is
fundamental.

> +muxed so as to not exceed the decoder side buffering or available bandwidth.

This can be achieved purely with codec bitrate constraints.

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

Unnecessary. Any timestamp works equally well for synchronizing the
clock as long as the receiver has an approximately accurate local
clock source and measures corrections over long periods.

Rich