[gstreamer-bugs] [Bug 585708] New: [adder] Wrong handling of flushing seeks

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=585708

  GStreamer | gst-plugins-base | Ver: git
           Summary: [adder] Wrong handling of flushing seeks
           Product: GStreamer
           Version: git
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: bilboed at gmail.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: ensonic at sonicpulse.de
     GNOME version: Unspecified
   GNOME milestone: Unspecified


When doing a *flushing* seek on an element/pipeline one expects the following
to happen synchronously:
* the event is sent
* some element will handle the seek
  * Sends out a FLUSH_START
  * Streaming stops
  * Figures out if it can handle the seek and if so configures itself
accordingly
  * Sends out a FLUSH_STOP
  * Returns True if the streaming thread will push data according to the
requested seek, else False
* The seek event push returns to the user with either True/False

If the seek is successfull, the streaming threads start pushing the newsegment,
tags and buffers (in that order, tags being optional).


This means that if one does the following on an element:
1. asynchronously blocks the source pad,
2. Sends a flushing seek which succeeds,
3. asynchronoulsy un-blocks the source pad.

... we expect the first thing to come out of the pad to be a new_segment.



With adder this is not the case, since the FLUSH_STOP event is sent from the
streaming thread and not from the thread that did the flushing seek (i.e. it
does not send those events synchronously).

Because of this... we end up with adder pushing out a stray FLUSH_STOP event...
and breaks the whole synchronization when used in GNonLin.

Adder (or maybe collectpads?) should be modified to collect the
flush_start/flush_stop events coming into its sink pads (which are received
synchronously) and send out FLUSH_STOP once all incoming streams have stopped
flushing in a synchronous fashion.


Because of this issue, using adder in GNonLin operations fail, which results in
any gnonlin-based software (pitivi and other various scripts) not being able to
do proper audio mixing.


I have tried to figure out what's wrong within adder in vain. But some commits
do look suspicious.
* 4228ba0c6b095da4cd24e76a576aff5733b6c91e. This commit message and the comment
in the code states that flush_stop should be sent (from the streaming threads)
if the seek failed... yet the code is doing it ... if the seek succeeds ! Are
the two comments wrong and the code correct... or the opposite ?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=585708.