[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

On Wed, Feb 06, 2008 at 08:41:22PM +0100, Michael Niedermayer wrote:
> On Wed, Feb 06, 2008 at 02:26:01PM -0500, Rich Felker wrote:
> > On Wed, Feb 06, 2008 at 08:02:10PM +0100, Michael Niedermayer wrote:
> > > The point is that this does NOT apply to the "mpeg design" with transmit_ts
> > > as the 11 extra seconds are transmitted during the 1000 low bitrate frames
> > > before.
> > 
> > This means that:
> > 
> > A. During these 1000 low bitrate frames, each frame was actually
> >    transmitted well-before its decode/presentation time, so you have a
> >    lot of latency.
> 
> No the transmitter has access to the whole transmission unless its a
> realtime transmission.

If we're talking about transmission latency, obviously the topic is
live streams.

> It really is a 0 vs. 11 second difference for
> the receier after you switch it on/or tune to the channel at the start.

You'll have to clarify perhaps with an example because you're not
making sense to me.

> > Anyway, transmit_ts is not necessary to do what you've described. It
> > works perfectly well in my design, modulo the above points which apply
> > either way. However due to the above, especially C, I consider this
> > very bad broadcast system design.
> [...]
> > > B. requires 11 seconds instead of 0 seconds initial preload in the example
> > >    (and iam still not sure if clocks could really be synchronized in all
> > >    cases)
> > 
> > Claiming 0 is simply false. See above.
> 
> No its not false, the receiver has a 0 second INITIAL preload requirement.
> At frame 1000 it has a 11 second preload requirementt. And the average
> should be around 5.5 seconds. Thats half of your suggestion.
> You can change all the numbers by a scalar of your choice, it remains your
> design needs 2x the latency on average.

Perhaps you could clarify what "my design" is, because I have no idea
what design of mine you're talking about that requires unnecessary
preload. Do you just mean the practice of always using the maximum
that could be needed for any part of the stream? Or something else?

> The main/stream headers are just needed once, if i switch channels around,
> i already have them after a few minutes for all channels. And wont want to
> wait for them ...

After a few minutes? Normally I want to see the video within 0.5 sec
of selecting a channel, not a few minutes later... If a viewer can
turn on the receiving device/program and begin watching at any moment,
infrequent header repetition simply does not work.

Rich