mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-22 07:08:23 +00:00
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
This commit is contained in:
parent
f35ec14d33
commit
199c8ba561
2 changed files with 9 additions and 9 deletions
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue