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

[Måns Rullgård]

Måns Rullgård <mans at mansr.com> writes:

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

No comments on this?

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