[gstreamer-bugs] [Bug 632782] New: [bin] set_state to PLAYING of non-toplevel bin might stop at PAUSED

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Oct 21 03:15:39 PDT 2010


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

           Summary: [bin] set_state to PLAYING of non-toplevel bin might
                    stop at PAUSED
    Classification: Desktop
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: mnauw at users.sourceforge.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


... particularly if NO_PREROLL element present in bin.

Since NO_PREROLL "eats" any ASYNC, occurrence of the former tends to trigger a
"fake async-done" to counter the latter, see e.g. gst_bin_add_func when adding 
a NO_PREROLL element, or decodebin2 change_state function forcing async_done
upon NO_PREROLL state change of bin.

In any case, bin_handle_async_done is triggered, which (silently) ignores
further state change to PLAYING assuming that (some) parent will take care of
it later on.  While that is the case in "normal" state changes, it need not be
so in more "advanced/dynamic" custom bin scenarios (decodebin2, etc etc),
depending on whether parents already reached PLAYING earlier or other
ASYNC_START are pending somewhere else.  Specific cases are in e.g. bug #628214
or bug #632656.

As such, this may be intended behaviour, but it might need some tweaking or
some warning/documentation indicating that a good old _set_state (..., PLAYING)
needs some caution as it may "fail" silently and would have to be replaced by
_set_state (..., PAUSED) followed by _set_state (..., PLAYING).

-- 
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.




More information about the Gstreamer-bugs mailing list