[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