[gst-devel] information on gst_segment_clip() and the GstBaseSink Class

[Martin Soto]

On Thu, 2006-02-23 at 14:22 +0530, Sameer Naik wrote:
...
> what im confused on is that :say a frame with timestamp 3 is received
> and displayed and say the next frame with timestamp 2 arrives (not sure
> whether this could happen :), or case where the display time of the
> nextframe frame has passed )... how will it be dropped... (if the
> segment itself is clipped then,.. it makes sense to me, if not then i
> wonder how it happens..)

First, as far as I know, only NEWSEGMENT events change the segment
limits, normal buffers will never do that. And, second: It should never
happen that you receive a buffer with timestamp 2 after one with
timestamp 3. If that happens, some element up the stream is buggy and
must be fixed.

> next thing is that in the basesink theres this case in the switch
> statement
> Case GST_CLOCK_EARLY:
> which prints "Buffer to late, rendering anyway"
> ...what is meant by buffer to late....
> is it that the display time has passed, but its rendering the frame
> or is it that the display time has not yet come but it is rendering...

It means the display time in the buffer is earlier than the current
time, or, in other words, the buffer arrived too late to the sink. This
is what would happen in your 2 after 3 example above: basesink will just
play the second buffer immediately because it arrived too late. It may
be, however, that the actual derived sink (alsasink, xvimagesink, etc)
decides to skip the material in the buffer, either partially or
completely.

M. S.