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

Rich Felker dalias at aerifal.cx
Thu Feb 7 05:32:14 CET 2008


On Thu, Feb 07, 2008 at 03:55:46AM +0100, Michael Niedermayer wrote:
> Hi
> 
> Heres a third try, the 
> first was transmit_ts with unspecified buffers
> second was transmit_ts with a single specified buffer
> 
> Here now comes the buffer state per syncpoint.
> It trivially allows the demuxer to find the needed preload, and allows
> trivial clock synchronization.
> 
> Iam not sure how much more or less device dependant this is. It surely
> looks better if one considers broadcasting at a higher bitrate than the
> intended one. (lower will fail as with all other proposals)
> 
> Also this is the smallest solution so far, and likely also has less
> overhead than the transmit_ts.

This proposal is less offensive, but I still maintain that it's
unnecessary. Can we please examine the actual numbers to evaluate my
claims that all real-world scenarios can be covered without any
additions to the spec? I can even make up some hypothetical cases like
you did before and show how my design handles them if what I've said
so far is too much abstract nonsense and handwaving. Or if you prefer
I can work on a formal proof of the various bounds on delays and
ability to correct clock skew, with nice formulas, etc.

Rich



More information about the NUT-devel mailing list