Pipeline freeze at preroll on embedded system

Julian Scheel julian at jusst.de
Mon Jan 21 00:43:41 PST 2013


Am Montag, den 21.01.2013, 08:23 +0100 schrieb Sebastian Dröge:
> On So, 2013-01-20 at 21:57 +0100, Julian Scheel wrote:
> 
> > > The GCond in question would usually be signalled when the state change
> > > from PAUSED to PLAYING happens in basesink (or when
> > > flushing/EOS/stepping). So what you could do is to check if
> > > 
> > > a) basesink is actually tried to be set from PAUSED to PLAYING (check if
> > > the change_state function is called)
> > 
> > Actually I debugged this and the PAUSED to PLAYING transition is never happening. I can see that gstbasesrc change_state is called for GST_STATE_CHANGE_NULL_TO_READY as well as GST_STATE_CHANGE_READY_TO_PAUSED, but never for GST_STATE_CHANGE_PAUSED_TO_PLAYING.
> > So now the question is why this would not happen?
> > From where would that transition be initiated?
> 
> In "gst-launch-1.0 fakesrc ! fakesink" it would happen from the
> application thread. See gstreamer/tools/gst-launch.c:1097

Ok, if I set a breakpoint at line 1097 it won't be reached.

But if I set a breakpoint at line 1075:
caught_error = event_loop (pipeline, TRUE, GST_STATE_PAUSED);
it fires. And after it halted there I can continue and the pipeline
works as expected. If the breakpoint is set to line 1076 it won't be
reached at all.
So my guess would be that entering the event_loop a little later
magically solves the issue because some lock is released before or
anything like that. Any thoughs from your side?

> This happens after getting the STATE_CHANGED message for the state
> change to PAUSED from the pipeline in "event_loop".
> 
> Backtrace would be something like:
> > #0  gst_base_src_change_state (element=0x7b0110, 
> >     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbasesrc.c:3579
> > #1  0x00007ffff7b335cc in gst_element_change_state (
> >     element=element at entry=0x7b0110, transition=<optimized out>)
> >     at gstelement.c:2594
> > #2  0x00007ffff7b33fa1 in gst_element_set_state_func (element=0x7b0110, 
> >     state=GST_STATE_PLAYING) at gstelement.c:2550
> > #3  0x00007ffff7b1bd8c in gst_bin_element_set_state (next=GST_STATE_PLAYING, 
> >     current=GST_STATE_PAUSED, start_time=0, base_time=1019601586303013, 
> >     element=0x7b0110, bin=0x7b60f0) at gstbin.c:2308
> > #4  gst_bin_change_state_func (element=0x7b60f0, 
> >     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2610
> > #5  0x00007ffff7b335cc in gst_element_change_state (
> >     element=element at entry=0x7b60f0, transition=<optimized out>)
> >     at gstelement.c:2594
> > #6  0x00007ffff7b33fa1 in gst_element_set_state_func (element=0x7b60f0, 
> >     state=GST_STATE_PLAYING) at gstelement.c:2550
> > #7  0x000000000040395e in main (argc=4, argv=0x7fffffffe1d8)
> >     at gst-launch.c:1097
> 
> > > and b) if and when the GCond is signalled (while waiting? before? is
> > > something else waiting at that time, in which case changing from SIGNAL
> > > to BROADCAST should help, etc).
> > 
> > As PAUSED_TO_PLAYING transition is not happening the GCond will not be signalled, right?
> 
> Yes, only when flushing/EOS otherwise.



More information about the gstreamer-devel mailing list