Pipeline freeze at preroll on embedded system

Sebastian Dröge sebastian.droege at collabora.co.uk
Sun Jan 20 06:48:51 PST 2013


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.

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)
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130120/0c67c34b/attachment-0001.pgp>


More information about the gstreamer-devel mailing list