anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
Hi Developers,

I am reading the design document on the sync and notice formulas to
calculate the running time and the stream time:

B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum

stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum

Anyone can explain to me why the running_time use abs_rate but
stream_time use abs_applied_rate?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
And I also found the explanation from gst_event_new_new_segment_full():
=====================================================
* The @applied_rate value provides information about any rate adjustment that
* has already been made to the timestamps and content on the buffers of the
 * stream. (@rate * @applied_rate) should always equal the rate that has been
 * requested for playback. For example, if an element has an input segment
 * with intended playback @rate of 2.0 and applied_rate of 1.0, it can adjust
 * incoming timestamps and buffer content by half and output a newsegment event
 * with @rate of 1.0 and @applied_rate of 2.0
---------------------------------------------------------------------------------------------

Can someone explain how and why the rate and applied_rate is changed
in above use case?

On Wed, Oct 19, 2011 at 10:14 AM, bcxa sz <[hidden email]> wrote:

> Hi Developers,
>
> I am reading the design document on the sync and notice formulas to
> calculate the running time and the stream time:
>
> B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>
> stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum
>
> Anyone can explain to me why the running_time use abs_rate but
> stream_time use abs_applied_rate?
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

Wim Taymans
In reply to this post by bcxa sz
On 10/19/2011 04:14 AM, bcxa sz wrote:
> Hi Developers,
>
> I am reading the design document on the sync and notice formulas to
> calculate the running time and the stream time:
>
> B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>
> stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum

The formula for stream time is wrong, it should be NS.time instead of
NS.accum..

>
> Anyone can explain to me why the running_time use abs_rate but
> stream_time use abs_applied_rate?

Because using the same value for both timelines does not give the
desired results..

Wim

> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

Wim Taymans
In reply to this post by bcxa sz
On 10/19/2011 05:16 AM, bcxa sz wrote:

> And I also found the explanation from gst_event_new_new_segment_full():
> =====================================================
> * The @applied_rate value provides information about any rate adjustment that
> * has already been made to the timestamps and content on the buffers of the
>   * stream. (@rate * @applied_rate) should always equal the rate that has been
>   * requested for playback. For example, if an element has an input segment
>   * with intended playback @rate of 2.0 and applied_rate of 1.0, it can adjust
>   * incoming timestamps and buffer content by half and output a newsegment event
>   * with @rate of 1.0 and @applied_rate of 2.0
> ---------------------------------------------------------------------------------------------
>
> Can someone explain how and why the rate and applied_rate is changed
> in above use case?

The easiest way to understand this is to take a piece of paper and write
down some timestamps and newsegment event values and then calculate the
stream time and running time of the timestamps.

The rate scales the running time so that playback is slower/faster.

The applied rate scales the stream time so that reported playback time
is slower/faster.

Wim

>
> On Wed, Oct 19, 2011 at 10:14 AM, bcxa sz<[hidden email]>  wrote:
>> Hi Developers,
>>
>> I am reading the design document on the sync and notice formulas to
>> calculate the running time and the stream time:
>>
>> B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>>
>> stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum
>>
>> Anyone can explain to me why the running_time use abs_rate but
>> stream_time use abs_applied_rate?
>>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
In reply to this post by Wim Taymans
Hi Wim,

Thanks for your explanation. Can you help me further?

On Wed, Oct 19, 2011 at 1:14 PM, Wim Taymans <[hidden email]> wrote:

> On 10/19/2011 04:14 AM, bcxa sz wrote:
>>
>> Hi Developers,
>>
>> I am reading the design document on the sync and notice formulas to
>> calculate the running time and the stream time:
>>
>> B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>>
>> stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum
>
> The formula for stream time is wrong, it should be NS.time instead of
> NS.accum..
>

Yes, you are right. Also I can not get the meaning of NS.time and
NS.accum from document. Can you explain a little bit on this?

>>
>> Anyone can explain to me why the running_time use abs_rate but
>> stream_time use abs_applied_rate?
>
> Because using the same value for both timelines does not give the desired
> results..
>
can you explain a little to me why?

> Wim
>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
In reply to this post by Wim Taymans
On Wed, Oct 19, 2011 at 1:17 PM, Wim Taymans <[hidden email]> wrote:

> On 10/19/2011 05:16 AM, bcxa sz wrote:
>>
>> And I also found the explanation from gst_event_new_new_segment_full():
>> =====================================================
>> * The @applied_rate value provides information about any rate adjustment
>> that
>> * has already been made to the timestamps and content on the buffers of
>> the
>>  * stream. (@rate * @applied_rate) should always equal the rate that has
>> been
>>  * requested for playback. For example, if an element has an input segment
>>  * with intended playback @rate of 2.0 and applied_rate of 1.0, it can
>> adjust
>>  * incoming timestamps and buffer content by half and output a newsegment
>> event
>>  * with @rate of 1.0 and @applied_rate of 2.0
>>
>> ---------------------------------------------------------------------------------------------
>>
>> Can someone explain how and why the rate and applied_rate is changed
>> in above use case?
>
> The easiest way to understand this is to take a piece of paper and write
> down some timestamps and newsegment event values and then calculate the
> stream time and running time of the timestamps.
>
Ok, I will do it. The time caculation and relationship really confused me a lot.

> The rate scales the running time so that playback is slower/faster.
>
> The applied rate scales the stream time so that reported playback time is
> slower/faster.
>
> Wim
>
>>
>> On Wed, Oct 19, 2011 at 10:14 AM, bcxa sz<[hidden email]>  wrote:
>>>
>>> Hi Developers,
>>>
>>> I am reading the design document on the sync and notice formulas to
>>> calculate the running time and the stream time:
>>>
>>> B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>>>
>>> stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum
>>>
>>> Anyone can explain to me why the running_time use abs_rate but
>>> stream_time use abs_applied_rate?
>>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
And one more question, if the absolute time wrap around (for example,
seek backward or backward trickmode) during playback, what will
happen?

From my understanding, the absolute clock should be always increasing.

But in our scenario (embedded system), the element which provide the
clock will makes absolute time wrap around because the absolute time
is got from video or audio PTS.

On Wed, Oct 19, 2011 at 2:59 PM, bcxa sz <[hidden email]> wrote:

> On Wed, Oct 19, 2011 at 1:17 PM, Wim Taymans <[hidden email]> wrote:
>> On 10/19/2011 05:16 AM, bcxa sz wrote:
>>>
>>> And I also found the explanation from gst_event_new_new_segment_full():
>>> =====================================================
>>> * The @applied_rate value provides information about any rate adjustment
>>> that
>>> * has already been made to the timestamps and content on the buffers of
>>> the
>>>  * stream. (@rate * @applied_rate) should always equal the rate that has
>>> been
>>>  * requested for playback. For example, if an element has an input segment
>>>  * with intended playback @rate of 2.0 and applied_rate of 1.0, it can
>>> adjust
>>>  * incoming timestamps and buffer content by half and output a newsegment
>>> event
>>>  * with @rate of 1.0 and @applied_rate of 2.0
>>>
>>> ---------------------------------------------------------------------------------------------
>>>
>>> Can someone explain how and why the rate and applied_rate is changed
>>> in above use case?
>>
>> The easiest way to understand this is to take a piece of paper and write
>> down some timestamps and newsegment event values and then calculate the
>> stream time and running time of the timestamps.
>>
> Ok, I will do it. The time caculation and relationship really confused me a lot.
>
>> The rate scales the running time so that playback is slower/faster.
>>
>> The applied rate scales the stream time so that reported playback time is
>> slower/faster.
>>
>> Wim
>>
>>>
>>> On Wed, Oct 19, 2011 at 10:14 AM, bcxa sz<[hidden email]>  wrote:
>>>>
>>>> Hi Developers,
>>>>
>>>> I am reading the design document on the sync and notice formulas to
>>>> calculate the running time and the stream time:
>>>>
>>>> B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>>>>
>>>> stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum
>>>>
>>>> Anyone can explain to me why the running_time use abs_rate but
>>>> stream_time use abs_applied_rate?
>>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

Wim Taymans
In reply to this post by bcxa sz
On 10/19/2011 08:58 AM, bcxa sz wrote:

> Hi Wim,
>
> Thanks for your explanation. Can you help me further?
>
> On Wed, Oct 19, 2011 at 1:14 PM, Wim Taymans<[hidden email]>  wrote:
>> On 10/19/2011 04:14 AM, bcxa sz wrote:
>>>
>>> Hi Developers,
>>>
>>> I am reading the design document on the sync and notice formulas to
>>> calculate the running time and the stream time:
>>>
>>> B.running_time = (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>>>
>>> stream_time =  (B.time_stamp - NS.start) / NS.abs_applied_rate + NS.accum
>>
>> The formula for stream time is wrong, it should be NS.time instead of
>> NS.accum..
>>
>
> Yes, you are right. Also I can not get the meaning of NS.time and
> NS.accum from document. Can you explain a little bit on this?

NS.time is the stream time associated with the NS.start value. It is
used in position reporting.

Every time a new segment event is received (and the update flag is
FALSE), NS.accum should be incremented with the duration of the previous
segment event. The purpose of this value is to keep track of the total
elapsed time taken up by all previous segments. It is used in the
calculation of the running_time and it is needed to make the
running_time increment monotonically. Again, a piece of paper and some
segments will illustrate this. Your use case should be the looping of
some media sample.

>
>>>
>>> Anyone can explain to me why the running_time use abs_rate but
>>> stream_time use abs_applied_rate?
>>
>> Because using the same value for both timelines does not give the desired
>> results..
>>
> can you explain a little to me why?

Because for negative playback rates, we want the running_time to
increment and the stream_time to decrement. We also want to be able to
independently control playback speed and position reporting.

Wim

>
>> Wim
>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
Hi Wim,

can you also help me clarify my below question?

From my understanding, the absolute clock should be always increasing
from gstreamer design point of view.

But in our scenario (embedded system), the element which provide the
clock will makes absolute time wrap around if seek backward or
backward trickmode because the element provide the clock with video or
audio PTS.

It will be against the assumption of gstreamer (absolute time should
always increase).

Do you think current my way will be the issue?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

Wim Taymans
On 10/19/2011 09:39 AM, bcxa sz wrote:
> Hi Wim,
>
> can you also help me clarify my below question?
>
>  From my understanding, the absolute clock should be always increasing
> from gstreamer design point of view.
Yes
> But in our scenario (embedded system), the element which provide the
> clock will makes absolute time wrap around if seek backward or
> backward trickmode because the element provide the clock with video or
> audio PTS.
You will need to wrap the clock inside a clock object that compensates
for those
time wraps. You can use gst_audio_clock_reset() to inform the default
audio clock
of such time wraps.

> It will be against the assumption of gstreamer (absolute time should
> always increase).
Yes, don't do it.
> Do you think current my way will be the issue?
If your current way is to make a buggy clock, then yes, you'll have
issues. It can be
easily made non-buggy, though.

Wim
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
On Wed, Oct 19, 2011 at 3:56 PM, Wim Taymans <[hidden email]> wrote:

> On 10/19/2011 09:39 AM, bcxa sz wrote:
>>
>> Hi Wim,
>>
>> can you also help me clarify my below question?
>>
>>  From my understanding, the absolute clock should be always increasing
>> from gstreamer design point of view.
>
> Yes
>>
>> But in our scenario (embedded system), the element which provide the
>> clock will makes absolute time wrap around if seek backward or
>> backward trickmode because the element provide the clock with video or
>> audio PTS.
>
> You will need to wrap the clock inside a clock object that compensates for
> those
> time wraps. You can use gst_audio_clock_reset() to inform the default audio
> clock
> of such time wraps.
>
>> It will be against the assumption of gstreamer (absolute time should
>> always increase).
>
> Yes, don't do it.
>>
>> Do you think current my way will be the issue?
>
> If your current way is to make a buggy clock, then yes, you'll have issues.
> It can be
> easily made non-buggy, though.
>
I am very interesting to know how to make non-buggy? :)

> Wim
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

Wim Taymans
On 10/19/2011 10:00 AM, bcxa sz wrote:

> On Wed, Oct 19, 2011 at 3:56 PM, Wim Taymans<[hidden email]>  wrote:
>> On 10/19/2011 09:39 AM, bcxa sz wrote:
>>> Hi Wim,
>>>
>>> can you also help me clarify my below question?
>>>
>>>   From my understanding, the absolute clock should be always increasing
>>> from gstreamer design point of view.
>> Yes
>>> But in our scenario (embedded system), the element which provide the
>>> clock will makes absolute time wrap around if seek backward or
>>> backward trickmode because the element provide the clock with video or
>>> audio PTS.
>> You will need to wrap the clock inside a clock object that compensates for
>> those
>> time wraps. You can use gst_audio_clock_reset() to inform the default audio
>> clock
>> of such time wraps.
>>
>>> It will be against the assumption of gstreamer (absolute time should
>>> always increase).
>> Yes, don't do it.
>>> Do you think current my way will be the issue?
>> If your current way is to make a buggy clock, then yes, you'll have issues.
>> It can be
>> easily made non-buggy, though.
>>
> I am very interesting to know how to make non-buggy? :)
uhm.. I gave you some tips above... Which part do you not understand?

Wim

>> Wim
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: anyone who can explain more on the difference between segment.abs_rate and segment.abs_applied_rate

bcxa sz
Thanks Wim. Let me try something then maby will back soon.

On Wed, Oct 19, 2011 at 4:05 PM, Wim Taymans <[hidden email]> wrote:

> On 10/19/2011 10:00 AM, bcxa sz wrote:
>>
>> On Wed, Oct 19, 2011 at 3:56 PM, Wim Taymans<[hidden email]>
>>  wrote:
>>>
>>> On 10/19/2011 09:39 AM, bcxa sz wrote:
>>>>
>>>> Hi Wim,
>>>>
>>>> can you also help me clarify my below question?
>>>>
>>>>  From my understanding, the absolute clock should be always increasing
>>>> from gstreamer design point of view.
>>>
>>> Yes
>>>>
>>>> But in our scenario (embedded system), the element which provide the
>>>> clock will makes absolute time wrap around if seek backward or
>>>> backward trickmode because the element provide the clock with video or
>>>> audio PTS.
>>>
>>> You will need to wrap the clock inside a clock object that compensates
>>> for
>>> those
>>> time wraps. You can use gst_audio_clock_reset() to inform the default
>>> audio
>>> clock
>>> of such time wraps.
>>>
>>>> It will be against the assumption of gstreamer (absolute time should
>>>> always increase).
>>>
>>> Yes, don't do it.
>>>>
>>>> Do you think current my way will be the issue?
>>>
>>> If your current way is to make a buggy clock, then yes, you'll have
>>> issues.
>>> It can be
>>> easily made non-buggy, though.
>>>
>> I am very interesting to know how to make non-buggy? :)
>
> uhm.. I gave you some tips above... Which part do you not understand?
>
> Wim
>>>
>>> Wim
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> [hidden email]
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel