[NUT-devel] Broadcasting nuts [PATCH]
Michael Niedermayer
michaelni at gmx.at
Thu Feb 7 14:45:22 CET 2008
On Wed, Feb 06, 2008 at 11:27:43PM -0500, Rich Felker wrote:
> On Thu, Feb 07, 2008 at 03:17:02AM +0100, Michael Niedermayer wrote:
> > > > 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.
>
> For all practical purposes, the viewer ALWAYS starts watching at some
> other point than the "beginning" which hardly even exists except at
> some distant point in history. _Broadcast_ means a unidirectional
> where all 'clients' receive the same thing, whatever is currently 'on
> the air'.
>
> Thus, I see the whole issue as unworthy of consideration. For genuine
> broadcast purposes, the buffering constraints must be such that
> clients can pick up and immediately start playing at any point in the
> broadcast. Transmitting low-bitrate parts faster-than-realtime, aside
> from over very short intervals, has no practical purpose in such an
> application because it will mean long intervals of time during which
> it's impossible to start watching the broadcast.
The example shown had a average preload of 5.5 sec with transmit_ts and >11
seconds with your methods.
>
> > "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
>
> 2 issues here:
>
> 1. I never said you're not allowed to transmit the first 1000 99-byte
> frames at 100 bytes/sec, only that the average difference between dts
> and transmit time over VERY LARGE windows needs to be constant.
This just scales the numbers, whichever window size you use you cannot
transmit data ahead in it at average.
> Here,
> very large means much larger than the buffer size but much smaller
> than the time scale on which the clock error grows too large. Unless
> your buffering (and worst-case preload time) is extremely huge or your
> clock is extremely bad, there will always be a HUGE (several orders of
> magnitude) margin of choice for the window size between these two
> bounds.
Whatever your acceptable clock drift is, it is effectivly added to the
buffer and preload requirement.
If like in your example 0.2 sec preload should be achived clock drift must
stay significantly below 0.2 sec. A clock drift of 0.1 sec would need a
0.3 sec preload to compensate. And at the same time would double the
buffer reqirement to 0.4 seconds. And dont forget that the buffer
and preload requirements were already at least doubled due to the use of
a global max preload instead of a per syncpoint one.
Now for example with a clock accurate to 1 minute per day its just about
2 minutes until you have a 0.1 second drift.
Also a clock which randomly (compared to systemtically) drifts will
drift faster on small time scales then long ones. The reason is
that the small random drifts will partially cancel each other.
If i now take the above case with 0.1sec in 2min drift requirement and
apply your several orders of magnitude (*100) then i need to keep the
buffer fill at some constant point at 1 sec windows. Thats a VERY nasty
constraint.
>
> 2. Even if you want to compare the version that cannot transmit
> anything faster-than-realtime (which is more restrictive than my
> proposal) to the version that can, the worst-case preload requirement
> is always the same. This stream is entirely unusable for broadcast
> purposes due to that fact.
Even this is false. Because you can only seek to keyframes and to
reach the worst case in my example you need to have a keyframe at the
single maximum preload point. In your case any point has the maximum.
But lets take another example to see that a factor of 2 is far from the
worst case.
channel bandwidth 100byte/sec 1fps
frame 0 dts 0 size 50 receive time 0
frame 1 dts 1 size 50 receive time 1
...
frame 990 dts 990 size 50 receive time 990
frame 991 dts 991 size 50 receive time 990.5
...
frame 1000 dts 1000 size 50 receive time 995
frame 1001 dts 1001 size 200 receive time 995.5
frame 1002 dts 1002 size 200 receive time 997.5
frame 1003 dts 1003 size 200 receive time 999.5
frame 1004 dts 1004 size 200 receive time1001.5
frame 1005 dts 1005 size 200 receive time1003.5
frame 1006 dts 1006 size 200 receive time1005.5
vs.
frame 0 dts 0 size 50 receive time 0
frame 1 dts 1 size 50 receive time 1
...
frame 1000 dts 1000 size 50 receive time 1000
frame 1001 dts 1001 size 200 receive time 1002
frame 1002 dts 1002 size 200 receive time 1004
frame 1003 dts 1003 size 200 receive time 1006
frame 1004 dts 1004 size 200 receive time 1008
frame 1005 dts 1005 size 200 receive time 1010
frame 1006 dts 1006 size 200 receive time 1012
The example which forbids pretransmit has a constant 6 sec preload
requirement.
The unrestricted variant has a worst case of 6 sec but its average is
0.06 sec.
Again everything can be scaled as you see fit, the *100 difference stays.
But its not hard to increase it to any value you pick.
>
> > 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.
>
> My proof of the ability to sync clocks always works as long as you
> treat the window of mean-difference sampling as being significantly
> larger than the receive buffer. Do I need to write it out formally?
No i dont doubt that if constraint X is imposed that you then can sync clocks.
What i doubt is that constraint X can be imposed without very significantly
larger buffers and preload requirements.
And a x2 worsening makes nut very unattractive. Its not a 0.1% vs 0.2%
overhead from which the end user wont see anything anyway. But a x2 delay
on seeking or startup. Which the user will notice.
>
> > > > 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.
>
> I think this argument is weak. Any broadcast scenario where there's a
> significant delay the first time you tune to a new channel has
> essentially zero chance of being market-viable. The headers will have
> to be repeated at least once every 2-3 seconds and probably 2-3 times
> per second...
Yes, this means 0.5 second delay.
The 2 byte buffer states can be transmitted 10 times per second for just
20byte/sec to give me 0.4 second faster access.
Transmitting vorbis headers for a dozen audio streams 10 times per second
is a completely idiotic requirement!
Also info packets are optional, the preload or transmit_ts are mandatory
thus cannot be in info packets unless we change the spec and make info
mandatory.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/b683c8d3/attachment.pgp>
More information about the NUT-devel
mailing list