[NUT-devel] Broadcast sufficiency - my assumptions/reasoning/design for it

[Rich Felker]

On Wed, Feb 06, 2008 at 06:27:47PM +0100, Michael Niedermayer wrote:
> On Wed, Feb 06, 2008 at 12:08:37PM -0500, Rich Felker wrote:
> > OK since there seems to be a disagreement (to put it lightly :) as to
> > what the current NUT framework can do for synchronizing timing between
> > a transmitter and receiver, I'd like to lay down the hypotheses and
> > reasoning I'm working from. Maybe others disagree on the basic
> > assumptions or haven't though of them. So, here it goes:
> > 
> > Transmitter side:
> > 
> > Key assumption is that frames are actually transmitted according to
> > dts. In a VBR transmission with immensely excessive bandwidth, or a
> > pure CBR (e.g. uncompressed, single-stream) transmission, this can be
> > done almost exactly. In CBR with buffer restraints, obviously it will
> > not be exact. 
> 
> > It is sufficient that the mean difference between dts
> > and actual transmission time be constant over intervals of time whose
> > length is on the order of the maximal length of time in which
> > transmitter and receiver clocks can be expected to remain within an
> > acceptable error relative to one another.
> 
> This is too vague to argue about it.

It's trivially true for any live broadcast or broadcast with a fixed
channel bitrate.

> Also the constraint proposed by you will multiple the buffer and
> latency relative to mpeg by huge integers. That is it wont be a

If you claim added latency you'll have to explain how. Since the
constraints are ALREADY met in all real-world applications, claiming
that they would add anything is nonsense IMNSHO.

> Also this would only solve ONE single problem brought up. Your design
> still leaves the preload time up to pure luck.

If you really need to know a minimum preload time, put it in a
protocol header or in the spec for the broadcast constraints.

> > I'd be very happy to see (maybe even help write) an RFC on
> > synchronization of unidirectional broadcast streams for arbitrary
> > streamable containers. Is anyone willing to consider that as a
> > constructive alternative to arguing about putting MPEG-type stuff in
> > NUT?
> 
> You can write whatever you like. This has no effect on me wanting nut
> to be useable for broadcast. If you cannot offer a solution now then iam
> not interrested in it.

It's already usable, as is any other existing streamable container. If
you continue to point out the ways in which you do not believe they
are usable, I will happily explain.

Rich