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

[Michael Niedermayer]

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.
Also the constraint proposed by you will multiple the buffer and
latency relative to mpeg by huge integers. That is it wont be a
viable alternative unless pushed by lies claiming it wouldn have
such disadvantages.
Also this would only solve ONE single problem brought up. Your design
still leaves the preload time up to pure luck.


[...]

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

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/b8cd1268/attachment.pgp>