[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Wed, Feb 06, 2008 at 01:28:40PM -0500, Rich Felker wrote:
> On Wed, Feb 06, 2008 at 07:19:14PM +0100, Michael Niedermayer wrote:
> > 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!
> 
> Um this has nothing to do with time synchronization. It's a simple
> fact that if you use a bitrate twice as large as your pipe for 11
> seconds, then you must either have 11 seconds of preload or your
> playback will get delayed. I don't see what point you're trying to get
> across.

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.

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

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.

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/2ca9d007/attachment.pgp>