[gst-devel] caps-nego halting state change

Matthew Romaine mromaine at parc.com
Fri Aug 2 22:19:12 CEST 2002 

Hello, 

	Following up on trying to fix caps-nego stuff, I have attached a test
program and a plugin on which it relies.  the plugin is a ripoff of the
the 'identity' element, and defines a caps for the pipeline to work. 
(the regular Makefile is for gainctl.c; everything else belongs to the
plugin)

	I poked around some more to see if I could figure out what is going on,
and noticed some behavior which I thought was odd.  I think the debug
output might be misleading me, but in gst_pad_perform_negotiate, the
caps are 'gotten' (via gst_pad_get_caps), and are then subsequently
'dumped', at least according to the debug output.  I wonder what exactly
is meant by 'dumped', as nothing seems to be actually happening on the
caps according to code.

	Also, if you look at the debugging output from the test file, you
should notice the following sequence of events:

DEBUG(12227: 0)gst_element_set_state:1904: [signal_src] setting state
from READY to PAUSED
INFO (12227: 0)gst_element_change_state:2057: signal_src default handler
sets state from READY to PAUSED 516
DEBUG(12227: 0)gst_element_negotiate_pads:1967: [signal_src] negotiating
pads
DEBUG(12227: 0)gst_element_negotiate_pads:2007: [signal_src] perform
negotiate for signal_src:src and decoder:sink

<snip -- caps nego stuff>

DEBUG(12227: 0)gst_element_set_state:1904: [decoder] setting state from
READY to PAUSED
INFO (12227: 0)gst_element_change_state:2057: decoder default handler
sets state from READY to PAUSED 516
DEBUG(12227: 0)gst_element_negotiate_pads:1967: [decoder] negotiating
pads
DEBUG(12227: 0)gst_element_negotiate_pads:2007: [decoder] perform
negotiate for signal_src:src and decoder:sink

<snip -- more caps nego stuff>

DEBUG(12227: 0)gst_element_set_state:1904: [tee] setting state from
READY to PAUSED
INFO (12227: 0)gst_element_change_state:2057: tee default handler sets
state from READY to PAUSED 516
DEBUG(12227: 0)gst_element_negotiate_pads:1967: [tee] negotiating pads
DEBUG(12227: 0)gst_element_negotiate_pads:2007: [tee] perform negotiate
for decoder:src and tee:sink

<snip -- more caps nego stuff, but then everything fails>

DEBUG(12227: 0)gst_pad_try_set_caps_func:1223: parent volume_filter of
pad volume_filter:sink is not paused
INFO (12227: 0)gst_pad_try_set_caps:1344: tried to set caps on peerpad
volume_filter:sink but couldn't
INFO (12227: 0)gst_pad_try_set_caps_func:1274: got reply REFUSED (-1)
from connect function on pad tee:sink
INFO (12227: 0)


What I am trying to point out is that just before each caps-nego, the
preceeding element switches states from READY to PAUSED, until the
element *after* the tee (in this case, volume).  For some reason,
volume's state is not changed like the others are before a negotiation
occurs, and this messes everything up.  I wonder if there is some
thread-related timing issue going on here...?


Let me know if you need me to poke around some more (and where to poke
around as well).

-matt




On Fri, 2002-08-02 at 01:34, Thomas Vander Stichele wrote:
> 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/
-- 
-------------------------
Matthew Romaine, Intern
Palo Alto Research Center
Distributed Systems, CSL 
650.812.4462
-------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gainctl.c
Type: text/x-c
Size: 2190 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20020802/a2e7f8ba/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: text/x-makefile
Size: 376 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20020802/a2e7f8ba/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstidentify.c
Type: text/x-c
Size: 4619 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20020802/a2e7f8ba/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstidentify.h
Type: text/x-c
Size: 940 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20020802/a2e7f8ba/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.in
Type: text/x-makefile
Size: 15641 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20020802/a2e7f8ba/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.am
Type: text/x-makefile
Size: 259 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20020802/a2e7f8ba/attachment-0005.bin>

More information about the gstreamer-devel mailing list