[gstreamer-bugs] [Bug 318116] New: new state change patch

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=318116
 GStreamer | gstreamer (core) | Ver: HEAD CVS

           Summary: new state change patch
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: wim at fluendo.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: all-bugs at bugzilla.gnome.org


current state change design is rather awkward for the programmer. When doing a
state change to PLAYING, for example, the set_state() function stops performing
the state change as soon as it receives ASYNC. The programmer is then supposed
to perform the next state changes manually. GstPipeline also does a blocking 
wait to reach the final state change, which might be infinite in case of errors. 

Performing downward state changes might block indefinatly in a similar way and
require the application programmer to be prepared to handle ASYNC state changes.

GstBin and subclasses also don't post state change messages automatically after
completing the state change unless explicitly polled for with
gst_element_get_state() which is again blocking.

Various hacks exist to work around these problems in gstutils.c
(gst_element_set_state_async and gst_bin_watch_for_state_change which both spawn
threads).

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.