From 199c8ba561cb641a86b12fd607dbbb3e73bc8661 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Tim-Philipp=20M=C3=BCller?= Date: Sat, 4 Apr 2015 18:18:03 +0100 Subject: [PATCH] docs: design: fix some 0.10-isms in GstSegment docs 1) segment.accum -> segment.base 2) Refer to GstSegment members as S.foo instead of NS.foo, the event is now called a segment event rather than newsegment event. 3) There's no more abs_rate field in GstSegment, and there never was an abs_applied_rate field. https://bugzilla.gnome.org/show_bug.cgi?id=690564 --- docs/design/part-streams.txt | 12 ++++++------ docs/design/part-synchronisation.txt | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/design/part-streams.txt b/docs/design/part-streams.txt index 3a95634..09cf074 100644 --- a/docs/design/part-streams.txt +++ b/docs/design/part-streams.txt @@ -41,7 +41,7 @@ Typical stream 2) SEGMENT, rate, start/stop, time - marks valid buffer timestamp range (start, stop) - marks stream_time of buffers (time). This is the stream time of buffers - with a timestamp of NS.start. + with a timestamp of S.start. - marks playback rate (rate). This is the required playback rate. - marks applied rate (applied_rate). This is the already applied playback rate. (See also part-trickmodes.txt) @@ -49,22 +49,22 @@ Typical stream against the clock. 3) N buffers - - displayable buffers are between start/stop of the SEGMENT. Buffers + - displayable buffers are between start/stop of the SEGMENT (S). Buffers outside the segment range should be dropped or clipped. - running_time: - if (NS.rate > 0.0) - running_time = (B.timestamp - NS.start) / NS.abs_rate + NS.accum + if (S.rate > 0.0) + running_time = (B.timestamp - S.start) / ABS (S.rate) + S.base else - running_time = (NS.stop - B.timestamp) / NS.abs_rate + NS.accum + running_time = (S.stop - B.timestamp) / ABS (S.rate) + S.base * a monotonically increasing value that can be used to synchronize against the clock (See also part-synchronisation.txt). - stream_time: - stream_time = (B.timestamp - NS.start) * NS.abs_applied_rate + NS.time + stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time * current position in stream between 0 and duration. diff --git a/docs/design/part-synchronisation.txt b/docs/design/part-synchronisation.txt index 8c67415..7694c1b 100644 --- a/docs/design/part-synchronisation.txt +++ b/docs/design/part-synchronisation.txt @@ -114,8 +114,8 @@ For S.rate > 1.0, the timestamps will be scaled down to increase the playback rate. Likewise, a rate between 0.0 and 1.0 will slow down playback. For negative rates, timestamps are received stop S.stop to S.start so that the -first buffer received will be transformed into B.running_time of 0 (B.timestamp == -S.stop and S.accum == 0). +first buffer received will be transformed into B.running_time of 0 +(B.timestamp == S.stop and S.base == 0). This makes it so that B.running_time is always monotonically increasing starting from 0 with both positive and negative rates. @@ -219,7 +219,7 @@ allows us to rewrite the above formula for stream_time (and for positive rates). filling (B.timestamp - S.start) in the above formule for stream time => - stream_time = (S.offset + (absolute_time - base_time - S.base) * ABS (S.rate)) * S.abs_applied_rate + S.time + stream_time = (S.offset + (absolute_time - base_time - S.base) * ABS (S.rate)) * ABS (S.applied_rate) + S.time This last formula is typically used in sinks to report the current position in an accurate and efficient way. -- 2.7.4