Well, problem fixed. Thanks for the help. The problem was actually with basesink. After a NEWSEGMENT event, gst_segment_init()<a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstSegment.html#gst-segment-init"> <code class="function"></code></a> is called, resetting the value returned by gst_segment_to_running_time() to 0. Now, if the pipeline has been running for 5 seconds prior to the seek event, the difference between basesink->base_time and the internal time of the pipeline clock would be 5 seconds. Therefore, gst_clock_wait_id() would return GST_CLOCK_EARLY for any buffer earlier than 5 seconds into the NEW (post-seek) segment. And that caused 5 seconds worth of buffers to be processed as fast as possible. I'm not sure if this is a problem with basesink, or just my usage of it (in which case, I'd appreciate knowing), but what I did to solve this was to reset basesink->base_time to the clock's internal time on a NEWSEGMENT event. Thanks, Itay. <div>On 8/25/07, Andy Wingo <<a href="mailto:wingo@pobox.com">wingo@pobox.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Fri 24 Aug 2007 23:08, "Itay Kirshenbaum" <<a href="mailto:ikirsh@gmail.com">ikirsh@gmail.com</a>> writes: > Is there any other element in that pipeline that can queue a large > number of buffers (rtpmp4vpay maybe? I'm not familiar with its > behavior), hence causing this problem? >     On Thu 23 Aug 2007 21:02, "Itay Kirshenbaum" <<a href="mailto:ikirsh@gmail.com">ikirsh@gmail.com</a>> writes: > >     > filesrc -> queue -> avidemux -> queue -> rtpmp4pay -> udpsink Try putting identities in between various elements, then run with gst-launch -v. See e.g. the output of gst-launch -v fakesrc ! identity ! fakesink. Cheers, Andy. -- <a href="http://wingolog.org/"> http://wingolog.org/</a> </blockquote></div>