[gst-devel] Using playbin2

[Jeffrey Barish]

On Sunday 14 June 2009 19:39:18 Michael Smith wrote:
> On Sun, Jun 14, 2009 at 4:10 PM, Jeffrey
>
> Barish<jeff_barish at earthlink.net> wrote:
> > Jeffrey Barish wrote:
> >> My code works fine with playbin.  When I change to playbin2 (by changing
> >> the parameter in the element_factory_make call), the code no longer
> >> plays and I
> >> get error messages on the bus.  The error message is
> >>
> >> <GstGError at 0x8ecc390>, 'gstplaybin2.c(1783): pad_added_cb
> >> (): /GstPlayBin2:player'
> >>
> >> Can someone tell me what this error message means?  Is there something
> >> that I am supposed to do to use playbin2 that I do not need to do with
> >> playbin?
> >>
> >> This problem occurs with version 0.10.22.
> >
> > Even though playbin2 is in base plugins, I eliminated this error by
> > installing gstreamer0.10-plugins-bad, which provides input-selector.
> > However, now GStreamer is terminating with a segmentation fault.
>
> Yeah, older versions of playbin2 required input-selector, which is in
> -bad. Newer versions make it optional; it'll be moved to -base before
> playbin2 is officially declared 'stable'.
>
> As for the crash - well, you'll have to tell us where it's crashing
> for us to be able to help you. However, I'd strongly suggest upgrading
> to the current version first, if you can.

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?

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.
-- 
Jeffrey Barish