Pipeline freeze at preroll on embedded system

[Julian Scheel]

Am 20.01.2013 um 15:48 schrieb Sebastian Dröge <sebastian.droege at collabora.co.uk>:

> On So, 2013-01-20 at 14:17 +0100, Julian Scheel wrote:
>> Hi Sebastian,
>> 
>> Am Sonntag, den 20.01.2013, 13:06 +0100 schrieb Sebastian Dröge:
>>> On So, 2013-01-20 at 12:46 +0100, Julian Scheel wrote:
>>>> Actually it does not really work. It just freezes at a later point
>>>> gst-launch-1.0 fakesrc is-live=true num-buffers=50 ! fakesink
>>>> will never terminate.
>>> 
>>> as discussed on Friday already I believe that this is something broken
>>> in the lower layers of your system already. You mentioned that the GLib
>>> main loop for example already causes problems.
>> 
>> This was an assumption after looking into the backtraces of the error
>> case. But actually I think I was wrong about that. So the backtraces
>> seem fine - the main loop is just waiting for an event to happen.
> 
> Hm right, that's what happens in your backtrace :)
> 
>>> Did you check if someone else had similar problems running a custom RPi
>>> distribution? Or do you know if someone is running a custom RPi
>>> distribution without this problems, and checked if you built the system
>>> the same way?
>> 
>> I could find noone with similiar problems so far. But actually buildroot
>> is shipping gstreamer-0.10 and glib 2.30 by default, so it's unlikely
>> that many people have done gstreamer-1.0 build. I update to glib 2.32
>> and gstreamer-0.10, which works fine. Then I update gstreamer to 1.0
>> which does not work.
>> Right now I am tryint to update to glib 2.34, maybe that helps.
>> 
>> 
>>> At least with Raspbian and Arch Linux on RPi this problems don't happen.
>> 
>> Raspbian and Arch don't use uclibc, do they? This might be an important
>> difference.
> 
> They both use (e)glibc, yes. Maybe the pthread implementation of uclibc
> has some behaviour differences compared to (e)glibc, which causes the
> GLib GConds to not work as expected.

Yes, that is what I think is most likely...

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

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