[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

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.


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

simplified


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

I would like to provide what is needed to make nut useable for broadcast.
If that ends similar to mpeg or not is not of importance to me.
The question here is, if it makes sense to specify precissely how buffering
works. After all even if it is specified here it depends on the
demuxer/decoder capabilities. And a demuxer/decoder which places the buffers
differently from how the idealized buffer model does, will likely need bigger
buffers. Thus it might be advantaneous to treat the FIFO placement like the
FIFO size. And rather specify them together for a specific profile or other
seperate spec.


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

agree


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

changed

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: broadcast2.patch
Type: text/x-patch
Size: 2637 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080206/271aa8e2/attachment.bin>
-------------- 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/271aa8e2/attachment.pgp>