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

[Rich Felker]

On Sun, Feb 17, 2008 at 03:47:27AM +0100, Michael Niedermayer wrote:
> On Mon, Feb 11, 2008 at 03:11:45AM +0100, Michael Niedermayer wrote:
> > On Sun, Feb 10, 2008 at 08:53:17PM -0500, Rich Felker wrote:
> > > On Mon, Feb 11, 2008 at 12:54:56AM +0100, Michael Niedermayer wrote:
> > > > 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.
> > > > 
> > > > Iam planing to commit this in 24h, if someone has objections / wants me
> > > > to wait say so.
> > > 
> > > Can you wait a little bit for some more discussion? I'm not rejecting
> > > it but I'd like to think it through more.
> > 
> > ok
> 
> ping, i waited a week ...
> Ill add a transmit_ts in 48h (without buffer model) unless there is some
> sort of discussion happening before.

transmit_ts or your other proposal? I think I like transmit_ts better
but I'd like to know the motivations behind how the decision is made
rather than a decision being made by default when no one discusses it.
Even though this is not a feature I'm particularly interested in.

Rich