[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Wed, Feb 06, 2008 at 08:55:06PM -0500, Rich Felker wrote:
> 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.

Well maybe i choose a bad word. I meant the time between the user switching
to a channel and the time until he sees a image is 0 sec vs. 11 sec.


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

Iam not talking about live streams, just a normal tv movie being broadcast
for example. Here the 99byte per frame can be transmitted faster than
realtime thus when the high bitrate 200byte per frames are reached. They are
already available to the decoder a few seconds before they are needed.

Of course if you dont start watching at the start but at some other point then
some larger preload might be needed.


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

"your design B." here was the case that the transmitter was not allowed to
transmit the first 1000 99bte frames at 100byte/sec but was limited to 
99bytes/sec. This causes a larger preload requirement at the start. And
without the transmission limit my proof of the impossibility to sync clocks
would apply.
And honestly i dont think the clocks can be synchronized reliably even with
some simple limits.


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

You missunderstood me. I meant if i cycle through all channels trying to find
something not being total trash (which might take a minute). I do afterwards
have all headers and wouldnt want to wait at all for them. That is i would
benefit from more frequent preoad/transmit_ts than just after the headers.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- Måns Rullgård
-------------- 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/20080207/319a66f8/attachment.pgp>