[gst-devel] facing problem using GST_SEEK_TYPE_CUR in gst_element_seek
sanjayg417 at gmail.com
Fri May 18 06:47:09 CEST 2007
On 5/17/07, Jan Schmidt <thaytan at noraisin.net> wrote:
> Edward Hervey wrote:
> > Hi,
> > If you only want to change the rate without changing the seek
> > positions, use GST_SEEK_TYPE_NONE/GST_CLOCK_TIME_NONE for the start
> > position also.
> Actually, this will generally cause some strangeness in the seeking,
> because the fast-forward will begin from the position that the SOURCE of
> the pipeline has reached. Due to buffering after the decoders, this is
> not the position that the user is seeing on the screen, so their
> trick-mode operation will commence with a jump in the position.
> What you want to do is query the current position of the playback, and
> use that with GST_SEEK_TYPE_SET to begin the trickmode from the exact
> position you want.
> Also bear in mind that almost no decoders and demuxers currently support
> backwards playback, so rate < 0 won't work in general. Fast forward and
> forward slow-motion should always succeed, however.
Hi, Thanks a lot to you all for your valueable suggestion. It is working
using GST_SEEK_TYPE_SET and position as suggested by Jan.
I have one more issue during fast-farward of video playback of .divx file
When I called gst_element_seek() function for seeking with this .divx file
format file then it is failing.
.divx file property is as follows (output of command '$file ocean.divx'):
"ocean.divx: RIFF (little-endian) data, AVI, 704 x 396, 25.00 fps, video:
DivX 5, audio: MPEG-1 Layer 3 (mono, 48000 Hz)"
I am using the following piece of code for seeking:
GstFormat fmt = GST_FORMAT_TIME;
gst_element_query_position (pipeline, &fmt, &pos);
gst_element_seek (pipeline, 2.0, GST_FORMAT_TIME,
Thanks in advance for any suggestion on this problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel