[Bug 792575] New: Switching a lot between pause/playing state, endless hanging of GST_STATE_WAIT inside gst_element_get_state_func
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Jan 16 13:48:11 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=792575
Bug ID: 792575
Summary: Switching a lot between pause/playing state, endless
hanging of GST_STATE_WAIT inside
gst_element_get_state_func
Classification: Platform
Product: GStreamer
Version: 1.12.4
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer (core)
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: meinemailingliste2 at online.de
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created attachment 366884
--> https://bugzilla.gnome.org/attachment.cgi?id=366884&action=edit
Logfile of error, error completely at the end of logfile
I am switching a small playback pipeline (on i.MX6)
splitmuxsrc->h264parse->v4l2h264dec->v4l2sink
again and again from pause to playing and back to pause by keypresses.
Just before setting the pipeline to state PLAYING,
I query the current state (just for debugging) via
GstStateChangeReturn rv;
GstState state;
rv = gst_element_get_state(m_pPipeline, &state, NULL, GST_CLOCK_TIME_NONE);
When pressing the key fast enough or just with the right speed,
the program is hanging. I located the hanging in above code,
especially in function gst_element_get_state.
Adding further debug info it seems it is hanging here
just between debug output "MIDDLE 2a" and "MIDDLE 2b":
/* MT safe */
static GstStateChangeReturn
gst_element_get_state_func (GstElement * element,
GstState * state, GstState * pending, GstClockTime timeout)
{
GstStateChangeReturn ret = GST_STATE_CHANGE_FAILURE;
GstState old_pending;
fprintf(stderr, "MMMM I am in gst_element_get_state_func START\n");
GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element, "getting state, timeout %"
GST_TIME_FORMAT, GST_TIME_ARGS (timeout));
GST_OBJECT_LOCK (element);
ret = GST_STATE_RETURN (element);
GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element, "RETURN is %s",
gst_element_state_change_return_get_name (ret));
fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 1\n");
/* we got an error, report immediately */
if (ret == GST_STATE_CHANGE_FAILURE)
goto done;
/* we got no_preroll, report immediately */
if (ret == GST_STATE_CHANGE_NO_PREROLL)
goto done;
/* no need to wait async if we are not async */
if (ret != GST_STATE_CHANGE_ASYNC)
goto done;
old_pending = GST_STATE_PENDING (element);
if (old_pending != GST_STATE_VOID_PENDING) {
gboolean signaled;
guint32 cookie;
fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 2\n");
/* get cookie to detect state changes during waiting */
cookie = element->state_cookie;
GST_CAT_INFO_OBJECT (GST_CAT_STATES, element,
"waiting for element to commit state");
/* we have a pending state change, wait for it to complete */
if (timeout != GST_CLOCK_TIME_NONE) {
gint64 end_time;
/* make timeout absolute */
end_time = g_get_monotonic_time () + (timeout / 1000);
signaled = GST_STATE_WAIT_UNTIL (element, end_time);
} else {
fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 2a\n");
GST_STATE_WAIT (element);
fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 2b\n");
signaled = TRUE;
}
...
}
In the beginning of the function gst_element_get_state_func
there is GST_OBJECT_LOCK (element);
Could there be some situation where we lock out the background task
from doing some change of state, but then wait till this background task
is finished?
How to continue analysis? An idea what could go wrong here?
Logfile of gstreamer attached.
--
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