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 |
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 |
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 |
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 |
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 |
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. > > 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 |
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 |
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 |
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 |
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 |
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. > > 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 |
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? :) 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 |
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 |
Free forum by Nabble | Edit this page |