No subject


Tue Oct 18 23:16:40 PDT 2011


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 <bcxa.sz at gmail.com> wrote:
> On Wed, Oct 19, 2011 at 1:17 PM, Wim Taymans <wim.taymans at gmail.com> wrot=
e:
>> On 10/19/2011 05:16 AM, bcxa sz wrote:
>>>
>>> And I also found the explanation from gst_event_new_new_segment_full():
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>>> * The @applied_rate value provides information about any rate adjustmen=
t
>>> that
>>> * has already been made to the timestamps and content on the buffers of
>>> the
>>> =A0* stream. (@rate * @applied_rate) should always equal the rate that =
has
>>> been
>>> =A0* requested for playback. For example, if an element has an input se=
gment
>>> =A0* with intended playback @rate of 2.0 and applied_rate of 1.0, it ca=
n
>>> adjust
>>> =A0* incoming timestamps and buffer content by half and output a newseg=
ment
>>> event
>>> =A0* 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 i=
s
>> slower/faster.
>>
>> Wim
>>
>>>
>>> On Wed, Oct 19, 2011 at 10:14 AM, bcxa sz<bcxa.sz at gmail.com> =A0wrote:
>>>>
>>>> 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 =3D (B.time_stamp - NS.start) / NS.abs_rate + NS.accum
>>>>
>>>> stream_time =3D =A0(B.time_stamp - NS.start) / NS.abs_applied_rate + N=
S.accum
>>>>
>>>> Anyone can explain to me why the running_time use abs_rate but
>>>> stream_time use abs_applied_rate?
>>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>


More information about the gstreamer-devel mailing list