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

[Michael Niedermayer]

On Thu, Feb 07, 2008 at 12:13:23PM -0000, Måns Rullgård wrote:
> 
> Michael Niedermayer wrote:
> > Hi
> >
> > Heres a third try, the
> > first was transmit_ts with unspecified buffers
> > second was transmit_ts with a single specified buffer
> >
> > Here now comes the buffer state per syncpoint.
> > It trivially allows the demuxer to find the needed preload, and allows
> > trivial clock synchronization.
> >
> > Iam not sure how much more or less device dependant this is. It surely
> > looks better if one considers broadcasting at a higher bitrate than the
> > intended one. (lower will fail as with all other proposals)
> >
> > Also this is the smallest solution so far, and likely also has less
> > overhead than the transmit_ts.
> 
> I believe this will work, but you still need to specify a reference
> model for the buffer management.  

Yes, i know. I am trying to move in small steps to avoid another day
of flaming.


> It will also require more effort on
> the receiver side to achieve exact clock recovery.  With a timestamp
> transmitted clock recovery is trivial, whereas this will require the
> receiver to measure the (perceived) received bitrate in order to work
> out the necessary clock adjustments.

No, i dont think that is needed.
My idea was not to store the number of bytes to preload beginning with the
syncpoint. But to store how much should be in the buffer the moment the
syncpoint is reached.
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)

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/6091155d/attachment.pgp>