[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