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

[Rich Felker]

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.

> But putting it in info packets just doesnt work without allowing
> changeable info. Putting it in streams is a huge mess and changing nothing
> wont work as has been shown and i belive isnt disputed anymore?

I agree that it probably won't work "optimally". I still think it's
reasonable to ask for transmit_ts-dts to remain constant over
moderate-sized windows, but Michael is correct that there are
bitrate-utilization gains to be made by bending this rule. So if
people want to make use of such gains, some solution is needed.

Rich