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

[Måns Rullgård]

Michael Niedermayer wrote:
> 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.

Just making sure.

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

Yes, that was my understanding as well.

> 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.  Knowing
also the magnitude of the error allows much more rapid convergence.
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, and for good
performance also measure incoming bitrate.

I am not saying this is unacceptable, only pointing out the added
complexity required in the receiver for equal performance.

-- 
Måns Rullgård
mans at mansr.com