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

diff --git a/docs/design/part-streams.txt b/docs/design/part-streams.txt
index 3a95634..09cf074 100644 (file)
--- 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 (file)
--- 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.