[gst-devel] seeking for testaudiosrc, volume etc

[Wim Taymans]

On Sun, 2005-10-23 at 19:41 +0200, Stefan Kost wrote:
> hi wtay,
> 
> I noticed that you did lots of seeking related changes. I'd like to add
> seeking to some audio-elements I use like: testaudiosrc, sinesrc,
> volume. I know that it may source absurd to add seeking to generator
> elements and effects. All these elements have controllable parameters
> and the controller works on timestamps. Thus the data-processing is
> time-dependent. Seeking for those elements basically mean to adjust that
> local timestamp, so that they request the corrent controller data the
> next time thay sync their parameters.
> 
> I was looking at the wavparse element to find out what one needs to do
> to support seeking. Is that the most complete one? Is there one that is
> simpler?
Wavparse is the most complete one. Basesrc also implements all seeking
now.

> 
> Is that the right way to do it?
Yep
> 
> * add srcpad_event function to element and handle GST_EVENT_SEEK
> * parse seek event and eventualy convert position into the wanted format
> (TIME, BYTES, ...)
> ** woudn't that be a canditate for utils
> * perform the seeking
> ** send flush event or pause task
> ** take stream_lock
> ** update element timestamps
> ** stop flush
> ** ev. send new_segemnt
> ** start task
> ** release stream_lock
> 
This is the correct sequence, yes. variations are possible, like sending
the new_segment in the streaming thread.

> I wonder a bit about the asymetrie
> * at start the is flush *or* pausing the task, but at end the task is
> always started
Sending a flush start downstream will unblock all streaming (such as
syncing on the clock etc..) it will also pause any task because every
push will receive a wrong-state return value. This means that the task
could be paused because you manually set it paused or the flush made it
pause, restarting at the end of the seek is therefore always needed. 

> * the stream_lock is taken after flush/pausing, but not release before
> unflush/starting

You have to flush first and then take the STREAM_LOCK because if any
push is blocked in a sinks somewhere, you cannot take the stream lock.
It is possible to send the flush_stop outside of the stream lock too.
This is less safe when elements are behaving badly though (if at all
possible because the core handles this normally).

Wim
 
> 
> Ciao
>   Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>