[gst-devel] Seek failing on paused pipeline

[Arnout Vandecappelle]

 Hoi David,

 Not that I know much about seeking, but since nobody else is replying, I 
will :-)

 There is no need to use a bus watch in order to wait for the state to change 
to paused.  Instead, you can simply do the following from main():

    gst_element_set_state(pipeline, GST_STATE_PAUSED);
    gst_element_get_state(pipeline, NULL, NULL, GST_CLOCK_TIME_NONE);

 The gst_element_get_state is required because setting the state to PAUSED 
happens asynchronously.

 The reason that you get 'stream is now ready' several times is that you get a 
bus message for the state change of each individual element; it's only the 
last one (that of the pipeline) that is actually OK.  In fact, trying to seek 
on the pipeline which is not yet completely prerolled (i.e. state is not yet 
PAUSED) causes the pipeline to remain in an erroneous state...

 When you set the state to PLAYING, the playing thread will run concurrently 
with your main thread.  Therefore, some output will already be generated in 
the file before you start seeking.  By delaying the PLAYING until after 
you've done the seek, you avoid this problem.

 Does this clarify things?
 Regards,
 Arnout

On Thursday 09 October 2008 17:36:28 David Banks wrote:
> Dear gst-devel,
>
> Further to my question a while back, I have now progressed to my next task.
> This time I'm trying to capture a section from a stream to a file, using
> gst_element_seek().  My program is included below.
>
> As you can see, I watch for state changes on the bus.  When the pipeline
> goes to PAUSED state, I perform the seek.  To quote the manual for
> gst_element_seek_simple: 'In a completely prerolled PAUSED or PLAYING
> pipeline, seeking is always guaranteed to return TRUE on a seekable media
> type.'  Since I seek while the pipeline is paused, I expect the program
> below to give the output:
>
> stream is now ready
> seek result: 1
>
> And 'output.wav' should contain the 10 second period from 10 to 20 seconds
> of '/home/amoe/test.ogg'.  In reality, I get this output:
>
> stream is now ready
> seek result: 0
> stream is now ready
> seek result: 0
> stream is now ready
> seek result: 0
> stream is now ready
> seek result: 0
> stream is now ready
> seek result: 0
> stream is now ready
> seek result: 1
>
> And 'output.wav' contains the entire decoding of 'test.ogg'.
>
> The really strange thing is that sometimes it will give the 10-second
> output I expect, maybe once in every 100 runs?  The console output will
> always be the same, though.
>
> I really don't know what's going on here.  As far as I can see, I'm not
> missing any events, and the seek should be executed before the pipeline
> goes to PLAYING state, so my first thought (that the whole file is getting
> decoded to 'output.wav' before the seek has a chance to be executed) should
> not be possible.
>
> Any ideas?
>
> Thanks,
> David

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933