[gst-devel] Using playbin2

Michael Smith msmith at xiph.org
Mon Jun 15 21:53:30 CEST 2009

> I created a test program to illustrate the problem.  The test program works
> unless I put a sleep(1.0) in the gobject loop.  (I run the gobject loop
> manually so that I can perform some additional operations each iteration.)
> That discovery got me thinking about the possibility that delays in my
> gobject loop were causing the problem.  I tried disabling the additional
> commands once GStreamer is playing (so that the only extra statement in the
> loop is the get_state).  The program then works.  It seems that the problem
> has to do with punctuality in dealing with the about-to-finish message.  With
> the additional commands disabled, if I have the loop sleep for a reasonable
> time (e.g., 50 ms), the program seg faults.  I have to reduce the sleep
> to 1 us before it stops seg faulting.  Is it possible that the timing in
> playbin2 is really this critical?  I have to read a socket, so I don't see a
> way to get the loop this tight -- not to mention the load on the system if
> the loop has to buzz this quickly (which goes to 100%).  Doing a blocking
> context iteration is normally the right solution, but then the loop loses
> track of the sockets.  I suppose that I am going to have to find a solution
> using multithreading so that the sockets are monitored in a loop separate
> from gobject.  I am still wondering about two things: (1) Is a seg fault the
> right thing to happen when handling of the about-to-finish message is tardy?
> I would have expected playbin2 to behave as it does when one is not
> monitoring about-to-finish, i.e., the buffer empties and we get an EOS
> message.  (2) I may be misinterpreting my findings, but it seems as if the
> time remaining in the buffer when the about-to-finish message is sent is
> about 1 us.  Shouldn't the message be sent sooner?

It is, of course, not normal for it to crash in this case. However,
since you're the only one that has mentioned this particular problem,
AND you're using an out of date version, I again strongly recommend
upgrading - if it still crashes then, please file a bug and we'll fix

The about-to-finish signal is emitted much sooner than 1us before EOS
normally; I don't know what you're doing to see that behaviour.

> I could post my test program if doing so would be helpful.
> As for running the latest version, I tried to make 0.10.23.  I got close.
> After making gobject, gstreamer was still finding the old gobject (the one
> provided by Ubuntu for running Gnome).  A message advised that I remove the
> old one, but had I done so all of Gnome would have been removed.  The basic
> problem is that I don't know what I'm doing.  I bet there's a way to tell
> configure where to find the right gobject.  I upgraded to Ubuntu 9.04 to get
> version 0.10.22.

Updating glib is not needed; just build gstreamer (and the gstreamer plugins).


More information about the gstreamer-devel mailing list