[NUT-devel] Broadcasting nuts [PATCH]
Michael Niedermayer
michaelni at gmx.at
Wed Feb 6 19:19:14 CET 2008
On Wed, Feb 06, 2008 at 01:01:15PM -0500, Rich Felker wrote:
> On Wed, Feb 06, 2008 at 06:46:08PM +0100, Michael Niedermayer wrote:
> > > On the other hand, if the sender is doing the correct
> > > thing and only sending at 99 bytes/sec, but the receiver sees it as
> > > 100 bytes/sec due to clock drift, there is no problem.
> >
> > Ohh there is a problem, your receiver requirement for initial preload
> > changed from 0 seconds to 11 seconds. Having 11 seconds delay after
> > every seek is something which ill leave to you to explain to the user.
> > Also as you dont want to store any hints on preload in the file the
> > receiver has to guess how much it has to preload.
>
> Absolutely not. The preload requirement is not changed. No one cares
> that the presentation time of a frame is off by 0.01 second (1%). In
> fact in real world applications it will be more like 0.1% or smaller,
> and with real world framerates that's less than 0.0001 sec.
No, rich _please_ TRY to read and think about the example.
What you say is complete utter nonsense. No frames are delayed by 0.01sec
your decoder will freeze for 10 seconds with what you suggest.
heres the case with the times updated:
Frame 0 dts 0 99byte received at 0
Frame 1 dts 1 99byte received at 1
Frame 2 dts 2 99byte received at 2
...
Frame 1000 dts 1000 99bytereceived at 1000
Frame 1001 dts 1001 200byte received at 1001
Frame 1002 dts 1002 200byte received at 1003
Frame 1003 dts 1003 200byte received at 1005
Frame 1004 dts 1004 200byte received at 1007
Frame 1005 dts 1005 200byte received at 1009
Frame 1006 dts 1006 200byte received at 1011
Frame 1007 dts 1007 200byte received at 1013
Frame 1008 dts 1008 200byte received at 1015
Frame 1009 dts 1009 200byte received at 1017
Frame 1010 dts 1010 200byte received at 1019
Frame 1011 dts 1011 200byte received at 1021
Frame 1012 dts 1012 99byte received at 1023
You receive this frame 11 seconds later than its dts, the first frame was
received exactly at its dts. Both transmitter and receiver have atomic clocks
there is no drift. And the receiver does receive every frame at its dts
until frame 1000 it has than 12 seconds to receive data which needs 23 seconds
to receive!
[...]
--
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/20080206/f45babd8/attachment.pgp>
More information about the NUT-devel
mailing list