[Bug 652562] basesink: stuck in GST_PAD_PREROLL_WAIT
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Wed Jun 15 08:56:56 PDT 2011
https://bugzilla.gnome.org/show_bug.cgi?id=652562
GStreamer | gstreamer (core) | git
Philip Jägenstedt <philipj> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #9 from Philip Jägenstedt <philipj at opera.com> 2011-06-15 15:56:50 UTC ---
First, sorry for all the spamming. I was indeed heading in the wrong direction.
The pipeline is in fact reaching PAUSED, I deduced that it wasn't from the fact
that a side-effect of it reaching PAUSED never happened:
case GST_MESSAGE_STATE_CHANGED:
if (GST_MESSAGE_SRC(msg) == GST_OBJECT_CAST(pipeline))
{
GstState oldstate, newstate, pending;
gst_message_parse_state_changed (msg, &oldstate, &newstate,
&pending);
if (oldstate == GST_STATE_READY && newstate == GST_STATE_PAUSED)
{
GstFormat format = GST_FORMAT_TIME;
gint64 duration;
if (gst_element_query_duration (pipeline, &format, &duration)
&& format == GST_FORMAT_TIME)
{
// post a gst_message_new_duration to the application
// we do this because GST_MESSAGE_DURATION usually isn't
posted by GStreamer, it seems
}
}
The side-effect that never happened was posting that duration message. However,
it wasn't because the pipeline wasn't reaching PAUSED, it was because
gst_element_query_duration failed. When this happens, seeking to offset 0 also
fails. I'm not sure why either fails, but that is the problem to go after, not
what I've been chasing in this bug.
Closing as invalid.
--
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