Re:

Il Tuesday 05 February 2008 22:41:49 Måns Rullgård ha
scritto:
> Michael Niedermayer <michaelnigmx.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.
> 

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Re:

Thread: Re: