[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Tue, Feb 05, 2008 at 11:34:59PM +0000, Måns Rullgård wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Tue, Feb 05, 2008 at 09:41:49PM +0000, Måns Rullgård wrote:
> >> 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.
> >
> > ok
> >
> >> 
> >> >              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.
> >
> > Frames cannot be split in nut, thus i think this is sufficient. Also there is
> > no problem in principle by instantaneosly inserting and removing a frame at
> > the same time. That is transmit_ts == dts.
> 
> I still think there's a problem.  Consider this sequence:
> 
>   syncpoint, transmit_ts=T
>   frame header, dts=T
>   frame data
> 
> With your rule, this would be valid, even though the frame data would
> not yet be received at the DTS of the frame.  Frames may be decoded
> instantaneously, but they are not received instantaneously.

Not in reallity, no. But theres nothing in the spec forbidding instantaneous
reception. Thus the file would be strictly speaking valid i think.


[...]
> >  Index tags:
> >  -----------
> >  
> > @@ -978,6 +986,39 @@
> >  
> >  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.
> > +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.
> > +Byte n of the file must be transmitted before or at the same time as byte n+1.
> 
> Is this just another way of saying that the stream must be transmitted
> sequentially?  

Yes, but, I am trying to be precisse, as you keep saying the spec isnt.
Sequentially, for example would strictly speaking disallow 2 bytes to be
transmitted in parallel over a 16bit bus. Not that i think anyone would
misunderstand it to mean that it might disallow that ...


> I try to avoid the word "file" when discussing
> streaming, since it is entirely plausible (I'd even say likely) that
> the data never exists as a file in the usual sense of the word,
> i.e. it is transmitted directly from an encoder source without
> intermediate storage (think of live broadcasts).

I tried to avoid stream so theres no ambiguity with audio/video streams.

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/aa34dc59/attachment.pgp>