Re:

On Tue, Feb 05, 2008 at 11:34:59PM +0000, Måns Rullgård
wrote:
> Michael Niedermayer <michaelnigmx.at> writes:
> 
> > On Tue, Feb 05, 2008 at 09:41:49PM +0000, Måns
Rullgård wrote:
> >> 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.
> >
> > 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

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