gstreamer/docs/design/part-segments.txt
Wim Taymans 84770e8437 Various documentation updates.
Original commit message from CVS:
* docs/design/part-events.txt:
* docs/design/part-gstbus.txt:
* docs/design/part-gstpipeline.txt:
* docs/design/part-messages.txt:
* docs/design/part-overview.txt:
* docs/design/part-segments.txt:
* gst/gstbin.c:
* gst/gstbuffer.c:
* gst/gstclock.c:
* gst/gstelement.c:
* gst/gstevent.c:
* gst/gstfilter.c:
* gst/gstiterator.c:
Various documentation updates.
2005-09-24 14:14:03 +00:00

61 lines
2.5 KiB
Text

Segments
--------
A segment in GStreamer denotes a set of media samples that must be
processed. A segment has a start time, a stop time and a processing
rate.
A media stream has a start and a stop time. The start time is
always 0 and the stop time is the duration (or -1 if unknown, for example
a live stream). We call this the complete media stream.
The segment of the complete media stream can be played by issuing a seek
on the stream. The seek has a start time, a stop time and a processing rate.
complete stream
+------------------------------------------------+
0 duration
segment
|--------------------------|
start stop
The playback of a segment starts with a source or demuxer element pushing a
newsegment event containing the start time, stop time and rate of the segment.
The purpose of this newsegment is to inform downstream elements of the
requested segment positions. Some elements might produce buffers that fall
outside of the segment and that might therefore be discarded or clipped.
ex.
filesrc ! avidemux ! videodecoder ! videosink
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 video decoder stores these values internally and forwards them to the
next downstream element (videosink, which also stores the values)
Since second 1 does not contain a keyframe, the avi demuxer starts sending
data from the previous keyframe which is at timestamp 0.
The video decoder decodes the keyframe but knows it should not push the
video frame yet as it falls outside of the configured segment.
When the video decoder receives the frame with timestamp 1, it is able to
decode this frame as it received and decoded the data up to the previous
keyframe. It then continues to decode and push frames with timestamps >= 1.
When it reaches timestamp 5, it does not decode and push frames anymore.
The stop time is important when the video format contains B frames. The
video decoder receives a P frame first, which is can decode but not push yet.
When it receives a B frame, it can decode the B frame and push the B frame
followed by the previously decoded P frame. If the P frame is outside of the
segment, the decoder knows it should not send the P frame.
Avidemux stops sending data after pushing frame with timestamp 5 and pushes
an EOS event downstream to finish playback.