14.3. Flow of data between elements and time

Now we will see how time information travels the pipeline in different states.

The pipeline starts playing. The source element typically knows the time of each sample. [1] First, the source element sends a discontinous event. This event carries information about the current relative time of the next sample. This relative time is arbitrary, but it must be consistent with the timestamp that will be placed in buffers. It is expected to be the relative time to the start of the media stream, or whatever makes sense in the case of each media. When receiving it, the other elements adjust their offset of the element time so that this time matches the time written in the event.

Then the source element sends media samples in buffers. This element places a timestamp in each buffer saying when the sample should be played. When the buffer reachs the sink pad of the last element, this element compares the current element time with the timestamp of the buffer. If the timestamp is higher or equal it plays the buffer, otherwise it waits until the time to place the buffer arrives with gst_element_wait().

If the stream is seeked, the next samples sent will have a timestamp that is not adjusted with the element time. Therefore, the source element must send a discontinous event.

Notes

[1]

Sometimes it is a parser element the one that knows the time, for instance if a pipeline contains a filesrc element connected to a MPEG decoder element, the former is the one that knows the time of each sample, because the knowledge of when to play each sample is embedded in the MPEG format. In this case this element will be regarded as the source element for this discussion.