[gstreamer-bugs] [Bug 621833] New: Setting a pipeline to NULL can sometimes fail due to core state changes going in the wrong direction

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=621833
  GStreamer | gstreamer (core) | git

           Summary: Setting a pipeline to NULL can sometimes fail due to
                    core state changes going in the wrong direction
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: msmith at xiph.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Created an attachment (id=163876)
 View: https://bugzilla.gnome.org/attachment.cgi?id=163876
 Review: https://bugzilla.gnome.org/review?bug=621833&attachment=163876

Add test to core testsuite that this works (currently fails)

It should always be possible to set a pipeline to NULL - this must not fail,
otherwise it's impossible to safely unref the pipeline. Because upwards state
changes CAN (and do) fail - for example, a filesink getting an error because
the destination is read-only - it's imperative that a downwards state change on
a pipeline never cause upwards state changes of elements inside it.

This is not currently the case - sometimes core will attempt to move an element
to a higher state as part of a downwards state change, and if that fails the
downwards state change will then fail. 

I thought this was handled in bug #368536, but that change does not fix the
problem entirely.

The attached test case fails on current git. I'll also attach the (hacky)
workaround I'm currently using - I don't know if this is the right approach,
though something similar was rejected previously, so I guess Wim doesn't like
this.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.