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.

-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most
aggravated
form of tyranny and slavery out of the most extreme liberty.
-- Plato

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Thu, Feb 07, 2008 at 03:55:46AM +0100, 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.

This proposal is less offensive, but I still maintain that
it's
unnecessary. Can we please examine the actual numbers to
evaluate my
claims that all real-world scenarios can be covered without
any
additions to the spec? I can even make up some hypothetical
cases like
you did before and show how my design handles them if what
I've said
so far is too much abstract nonsense and handwaving. Or if
you prefer
I can work on a formal proof of the various bounds on delays
and
ability to correct clock skew, with nice formulas, etc.

Rich
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Thursday 07 February 2008 03:55:46 Michael Niedermayer
wrote:
> 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.
>

> +buffer_fullness (v)
> +  for broadcast mode:
> +    The number of bytes the demuxer is supposed to
have in its
> buffer. If +    less data than that is in the buffer
then the
> decoders should be slowed +    down to allow the buffer
to fill up.
> If more data than that is in the +    buffer then the
decoders
> should be speed up.

to me "fullness" conveys an idea of percentage
that doesn't fit
wth the descripion you gave of this item. Why not call it 
min_buffer_size?


_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Nico Sabbi wrote:
> On Thursday 07 February 2008 03:55:46 Michael
Niedermayer wrote:
>> 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.
>>
>
>> +buffer_fullness (v)
>> +  for broadcast mode:
>> +    The number of bytes the demuxer is supposed to
have in its
>> buffer. If +    less data than that is in the
buffer then the
>> decoders should be slowed +    down to allow the
buffer to fill up.
>> If more data than that is in the +    buffer then
the decoders
>> should be speed up.

Please fix your quoting.

> to me "fullness" conveys an idea of
percentage that doesn't fit
> wth the descripion you gave of this item. Why not call
it
> min_buffer_size?

If you find "fullness" confusing, perhaps it could
be called
"buffer_level" instead.  Either way, the value is
exact, not
a minimum.

-- 
Måns Rullgård
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

-- 
Måns Rullgård
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Thu, Feb 07, 2008 at 03:55:46AM +0100, 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.

Iam planing to commit this in 24h, if someone has objections
/ wants me
to wait say so.
But putting it in info packets just doesnt work without
allowing
changeable info. Putting it in streams is a huge mess and
changing nothing
wont work as has been shown and i belive isnt disputed
anymore?

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

No great genius has ever existed without some touch of
madness. -- Aristotle

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Måns Rullgård <mansmansr.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
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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)


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

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.

And if all else fails, something like the following should
do:

buffer_fullness += in_bytes;
buffer= realloc(buffer, sizeof(packet)*(buffer_index+1));
buffer[buffer_index].dts = in_dts;
buffer[buffer_index].size= in_bytes;
for(i=0; i<buffer_index; i++){
    if(buffer[i].dts > current_time)
        break;
    buffer_fullness -= buffer[i].size;
}
buffer_index++;
memmove(buffer, buffer+i, sizeof(packet)*(buffer_index-i));
buffer_index -= i;

Anyway if you say a timestamp would be better, i suspect
rich would be harder
to convince than me.

[...]

-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? --
Diogenes of Sinope

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel