[gst-devel] Pipeline seek problem

Itay Kirshenbaum ikirsh at gmail.com
Sun Aug 26 23:36:46 CEST 2007

Well, problem fixed. Thanks for the help.

The problem was actually with basesink.

After a NEWSEGMENT event,
called, resetting the value returned by gst_segment_to_running_time()

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

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


On 8/25/07, Andy Wingo <wingo at pobox.com> wrote:
> On Fri 24 Aug 2007 23:08, "Itay Kirshenbaum" <ikirsh at gmail.com> 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" <ikirsh at gmail.com>
> 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.
> --
> http://wingolog.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070827/d4f389ae/attachment.htm>

More information about the gstreamer-devel mailing list