[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

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.

B. Likewise, fairly large buffers are required for the player.

C. If the viewer tunes in right at the time when these 11 seconds of
   high-bitrate content are supposed to start, there will be a
   significant preload time before any content can be presented.

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.

> Thus my design / mpeg design has optimal preload and buffer requirements.
> Your design either
> A. cannot synchronize clocks (if you keep the transmitter as flexible as in
>    mpeg)

As long as even minimal effort is made to perform the transmission in
sync with actual time, it can and will synchronize the receiver's
clock such that buffers will not overflow or underflow. Normally no
effort is required beyond the constraints that are already met.

Note that the window used for comparing mean dts/receive_timestamp
differences can always be made proportional to the receiver's buffer
size, since the whole point is to prevent buffer over/underflow and
since the transmission rate cannot vary from actual time by more than
the amount that can be buffered.

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

> And for both A and B the demuxer does not know what preload it needs to use
> it has to guess. And thus it will have to guess higher to be sure its large
> enough -> more preload and thus latency and buffering than what mpeg would
> need.

I told you, you're totally welcome to add an info packet with preload
amount and other bitrate/buffer requirement information. Now if you
want to ask whether this info packet is available right away when the
receiver starts listening to the broadcast, well that's another issue
entirely. You see, all the main/stream headers are needed, but they
won't be available until the next time they're repeated if the
broadcast is purely unidirectional. As long as you have this issue,
it's ridiculous to try to tune NUT for broadcast usage. One certainly
could repeat the headers once per preload-interval if desired, of
course, or obtain them from some out-of-band source, but the latter
would be way outside the scope of NUT...

Rich