[NUT-devel] Another suggestion for broadcast [PATCH]

[Michael Niedermayer]

On Tue, Feb 19, 2008 at 08:19:39PM +0000, Måns Rullgård wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > +transmit_ts (t)
> > +    The timestamp at which the first bit of the syncpoint is transmitted.
> 
> In MPEG-TS, the PCR value is the time of arrival of the last bit
> (actually the byte containing the last bit).  This could be seen as
> more logical, as then no timestamp will refer to a time in the past.
> I doubt the distinction is relevant in practice, but I wanted to point
> it out nonetheless.

Last bit of what? The transmit_ts or the syncpoint?
A well written demuxer/receiver will check the crc of the syncpoint before
using transmit_ts thus it would still be in the past if its the last bit
of transmit_ts.
Also either way transmit_ts is variable length and that would slightly
complicate setting it exactly to the time of the last bit.


> 
> > +    MUST be less than or equal to all following dts.
> 
> I'm not happy with this.  It allows the clock to reach the DTS of a
> frame before the frame has arrived.  Placing restrictions on the
> transmit_ts value is not sufficient to avoid this condition.  Instead,
> it must be a rule that a frame must be completely received before the
> reference clock reaches its DTS value.

What about:

transmit_ts (t)
    The value of the reference clock at the moment when the first bit of
    transmit_ts is transmitted/received.
    The reference clock MUST always be less than or equal to the DTS of
    every not yet completely received frame.

?


> 
> > +    Demuxers in non broadcast mode MUST ignore the value of this field.
> 
> Why does it matter what demuxers do with it?

Rich?


> 
> > +    Muxers in broadcast mode MUST NOT ommit this field.
> 
> "omit"

Fixed

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20080219/b17735b1/attachment.pgp>