[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

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


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


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

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080206/096d3408/attachment.pgp>