flushing vs. non-flushing seek

[Tim Müller]

On Mon, 2015-07-13 at 14:43 +0200, Christian Sell wrote:

Hi Christian,

> I am trying to understand the purpose and working of non-flushing
> seek. Heres my scenario:
>  
> (Preamble)
> - due to the specifics of my UI, I am doing one  seek to adjust
> playback rate, directly followed by a seek that changes the playback
> segment.
> - previous to each seek operation, I am doing a query for the current
> position
> - the position query fails for the second seek ("wrong state"). The
> only explanation I could find was that the first seek, being called
> with a GST_SEEK_FLAG_FLUSH parameter, discards all position
> information.

Right, if you do a position query whilst the pipeline is flushing
(between flush-start and segment events), it might fail.

> (Problem)
> - I therefore decided to execute the first seek without
> the GST_SEEK_FLAG_FLUSH flag.
> - when I call the seek with a GST_SEEK_FLAG_NONE, my application
> completely BLOCKS!!
>  
> I investigated into the execution stack, and found that the sending of
> the seek event went directly into a code sequence in
> gst_base_src_perform_seek:
>  
>   if (flush) {
>     ...
>   } else
>     gst_pad_pause_task (src->srcpad);
> 
> 
> and in gst_pad_pause_task the call gets blocked on
> GST_PAD_STREAM_LOCK (pad);
> 
> can someone tell me what I am missing here? There must be something
> fundamental, because the results are so detrimental..

The STREAM_LOCK basically waits for the streaming thread to stop/exit.

In case of a flushing seek that's done when downstream returns
FLOW_FLUSHING (after the seeking thread sent flush-start events through
the pipeline).

You would typically only do a non-flushing seek when you know the
streaming has stopped e.g. if you're looping and the
source/demuxer/parser has sent a SEGMENT_DONE message (instead of an
EOS; when a SEGMENT seek was requested). In the looping case the first
seek would be a FLUSH|SEGMENT one, to position the source at the initial
position, and subesequent ones would be done on receiving a SEGMENT_DONE
message without flushing.

One could argue that perhaps the source should set a flag to let the
streaming thread know to shut down anyway in this case, I'm not sure if
the behaviour you're seeing is on purpose or not and should be like that
or not.

 Cheers 
  -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com