[NUT-devel] Another suggestion for broadcast [PATCH]

[Michael Niedermayer]

On Mon, Feb 11, 2008 at 12:14:20PM -0000, Måns Rullgård wrote:
> 
> Michael Niedermayer wrote:
> > On Thu, Feb 07, 2008 at 01:58:32PM -0000, Måns Rullgård wrote:
> >>
> >> Michael Niedermayer wrote:
> > [...]
> >> > That way the buffer_fullness stored in the syncpoint will always match
> >> > exactly the amount the decoder has in its buffer when reading the
> >> > syncpoint. If it has more in its buffer it just would change its clock
> >> > to one running at 100.1% and when it has less in its buffer it would
> >> > choose a 99.9% clock as reference. (Or any approximetaly equivalent
> >> > process)
> >>
> >> That the buffer fullness is off by N bits doesn't tell you how much too
> >> fast or too slow your clock is, only the sign of the error.
> >
> > yes
> >
> >
> >> Knowing
> >> also the magnitude of the error allows much more rapid convergence.
> >
> > I am not so sure about this. I mean i dont dispute that more information
> > should improve it, but i think its good enough with the too much/too little.
> >
> > A simple example, lets assume we have a decoder with a clock that drifts
> > by up to D between syncpoints.
> > That is, in the most ideal case we would have to accept that we are
> > D off when we reach a syncpoint, assuming we synced to the previous
> > perfectly.
> >
> > Now lets assume that we are within -2D .. +2D at syncpoint x, and we apply
> > a +D correction if we are <0 and -D if we are >0. This correction could be
> > applied slowly until the next syncpoint. What matters is that after the
> > correction we are within -D .. +D and with the drift thats again -2D .. +2D
> > at syncpoint x+1.
> > Thus above is a proof by induction that just knowing the sign and the worst
> > case clock drift is sufficient to be within a factor of 2 of the best
> > achiveable clock sync. (comparing worst cases, not average)
> 
> This is not how clock sync is usually done.  A typical implementation
> involves a PLL-type construct to make the local clock accurately track
> the sender clock.  Once locked, there is very little drift.  To correctly
> compensate for what little drift inevitably remains, the size of the
> error must be known.

Could you elaborate on how PLL based clock sync with transmit ts works?
I am no PLL expert, what i know is more of the sort that a PLL takes a
reference signal like a sine wave as input, not occasional scalars which
represent time since some point 0.
Iam also fine with a RTFM + an url.



> 
> The time difference can of course be computed from the difference in buffer
> fullness and the received bitrate, it merely takes a little more work on
> the receiver side.

instead of transmit_ts one can use
internal_clock_ts + (buffer_fullness < real_fullness ? D : -D)
That should provide a pretty good reference for the PLL IMHO


> 
> >> Providing the timestamp in the stream makes this trivial and independent
> >> of the buffering mechanism actually used.  Only specifying expected
> >> buffer fullness (according to a reference model) requires that the
> >> receiver at the very least simulate the reference model,
> >
> > I think most receivers will use something quite similar to the reference
> > model thus making this unneeded. Though yes a receiver using a different
> > buffer model might need to simulate the reference one.
> 
> I think it very unlikely that any real implementation will use whatever
> precise buffer model we choose.  Just about any implementation is
> likely to immediately extract the elementary streams of interest, and
> discard everything else, such as container headers and unwanted elementary
> streams.

Well we can discard the container headers as well in the reference model.


> 
> > But i have difficulty imageing a sufficiently different buffer model.
> > I mean a receiver with split buffers could just be taking the sum of
> > their buffer_fullness.
> > A reciver which removes packets later or not instantaneously would just
> > traverse the last few packets to find out how much the refernce buffer
> > would contain.
> 
> I'm not saying it would very difficult to simulate the reference buffer,
> but something is always more than nothing.

yes but OTOH transmit_ts would not scale nicely with increased bandwidth.
Do you have some suggestions here to avoid this disadvantage?

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20080211/cc5a1ed0/attachment.pgp>