[gst-devel] Pipeline seek problem
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>
> > > 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 !
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel