[gst-devel] Pipeline seek problem

[Itay Kirshenbaum]

Well, problem fixed. Thanks for the help.

The problem was actually with basesink.

After a NEWSEGMENT event,
gst_segment_init()<http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstSegment.html#gst-segment-init>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.

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>