[gst-devel] caps-nego halting state change

Thomas Vander Stichele thomas at urgent.rug.ac.be
Fri Aug 2 03:24:17 CEST 2002


Hi,


> after all elements are created and connected, everything starts off in
> the NULL state by default (right?).  

Yes.

When I initiate a state-change of
> the main-thread to PLAYING, its children elements must first transition
> to the READY state, which happens just fine.  But when the children must
> then transition to the PAUSED state, caps-nego is initiated between the
> children elements, and because in one case it fails, the whole
> transition change fails as well.
> 
> I have determined the caps-nego failure to be because an element is not
> in the PAUSED state, as per below debug output (full output at bottom of
> email):
> 
> DEBUG( 2490: 0)gst_pad_try_set_caps_func:1223: parent user0_volume0 of
> pad user0_volume0:sink is not paused     <------------------
> INFO ( 2490: 0)gst_pad_try_set_caps:1344: tried to set caps on peerpad
> user0_volume0:sink but couldn't
> INFO ( 2490: 0)gst_pad_try_set_caps_func:1274: got reply REFUSED (-1)
> from connect function on pad user0_tee:sink
> INFO ( 2490: 0)gst_pad_try_set_caps_func:1284: pad user0_tee:sink
> doesn't accept caps
> DEBUG( 2490: 0)gst_element_set_state:1935: [user0_tee] have failed
> change_state return

Hm.  From browsing through the tee code, as well as judging from what your 
debug output tells me, it looks like it's first trying to negotiate 
between a src tee pad and it's peer's sink pad.  I would find that the 
wrong behaviour for a tee, IMO.  I'd feel the tee should always have it's 
caps set from a connect on the sink pad, since that is the data that gets 
copied multiple times.

I was surprised though to not find any code pertaining to connection of 
the src pads.  Other people will need to help me to affirm or deny that 
the way it is now, tee gets a default connection handler for connections 
on it's src pads.  Wim, Andy, Erik, ... ?

So, I'm a bit confused too as to how the tee should work, and maybe we 
should outline that or design that properly - I'm willing to implement it, 
I want to fix up plug-ins so I can help flesh out the PWG.

My initial idea would be to have tee always return delayed when getting a 
nego request on a src pad.  I don't know if that will work well in cases 
where you don't actually request tee src pads, and just have a standard 
pipeline like ... ! tee ! volume ! ...

One other possible implementation I could think of would have one "always" 
src pad, which would be allowed to proxy caps and do caps nego, with the 
request pads being identical copies.

Maybe it's getting time to describe/design plug-in code a little ;) Source 
code gets confusing because it hides a lot of the gstreamer-specific 
idioms.


Back to Matt, though - is there source code from you we can look at to 
help debug ?

Thomas


The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
My baby she knows
the weight that I'm under
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/





More information about the gstreamer-devel mailing list