From 97ec47cabb1eb2280cf14f334f4264d5cb7e6a88 Mon Sep 17 00:00:00 2001 From: Wim Taymans Date: Mon, 13 Oct 2008 17:19:25 +0000 Subject: docs/design/part-TODO.txt: Remove item from the todo list because it was fixed with the latency state change rewrites. Original commit message from CVS: * docs/design/part-TODO.txt: Remove item from the todo list because it was fixed with the latency state change rewrites. * docs/design/part-seeking.txt: * docs/design/part-segments.txt: Update some docs. * gst/gstevent.c: (gst_event_new_new_segment_full), (gst_event_parse_new_segment_full), (gst_event_new_buffer_size), (gst_event_parse_buffer_size), (gst_event_new_qos), (gst_event_parse_qos), (gst_event_new_seek), (gst_event_parse_seek), (gst_event_new_latency), (gst_event_parse_latency): Use quarks to construct and parse events. * gst/gstquark.c: (_priv_gst_quarks_initialize): * gst/gstquark.h: Add some more quarks to the table. Emit a warning when the quark tables are not in sync. * tests/check/gst/gstbus.c: (GST_START_TEST): Add an assert. --- docs/design/part-segments.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'docs/design/part-segments.txt') diff --git a/docs/design/part-segments.txt b/docs/design/part-segments.txt index 7d57b71fad..afd0eb4cc9 100644 --- a/docs/design/part-segments.txt +++ b/docs/design/part-segments.txt @@ -38,6 +38,13 @@ Use case: FLUSHING seek When doing a seek in this pipeline for a segment 1 to 5 seconds, avidemux will perform the seek. + Avidemux starts by sending a FLUSH_START event downstream and upstream. This + will cause its streaming task to PAUSED because _pad_pull_range() and + _pad_push() will return WRONG_STATE. It then waits for the STREAM_LOCK, + which will be unlocked when the streaming task pauses. At this point no + streaming is happening anymore in the pipeline and a FLUSH_STOP is sent + upstream and downstream. + When avidemux starts playback of the segment from second 1 to 5, it pushes out a newsegment with 1 and 5 as start and stop times. The stream_time in the newsegment is also 1 as this is the position we seek to. @@ -57,18 +64,21 @@ Use case: FLUSHING seek When it reaches timestamp 5, it does not decode and push frames anymore. The video sink receives a frame of timestamp 1. It takes the start value of - the previous newsegment and aplies the folowing formula: + the previous newsegment and aplies the folowing (simplified) formula: render_time = BUFFER_TIMESTAMP - segment_start + element->base_time - It then syncs against the clock with this render_time. Not that + It then syncs against the clock with this render_time. Note that BUFFER_TIMESTAMP is always >= segment_start or else it would fall outside of the configure segment. - Videosink reports its current position as: + Videosink reports its current position as (simplified): current_position = clock_time - element->base_time + segment_time + See part-synchronisation.txt for a more detailed and accurate explanation of + synchronisation and position reporting. + Since after a flushing seek the stream_time is reset to 0, the new buffer will be rendered immediatly after the seek and the current_position will be the stream_time of the seek that was performed. -- cgit v1.2.3