After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 123237 - REQUEST pad lifecycle needs documentation, element utils need corresponding updates
REQUEST pad lifecycle needs documentation, element utils need corresponding u...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: documentation
git master
Other other
: Normal major
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 156380 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-09-25 19:55 UTC by Benjamin Otte (Company)
Modified: 2012-09-28 18:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benjamin Otte (Company) 2003-09-25 19:55:50 UTC
Currently GST_PAD_SOMETIMES and GST_PAD_REQUEST pads that appear depending
on the data or are requested never disappear until the element is disposed.

There needs to be a policy on how these are handled and they need to
disappear automatically.

This is required to make reuse of pipelines work, so I'll flag that as major.
Comment 1 David Schleef 2003-09-29 23:47:10 UTC
Pads can be removed from elements by gst_element_remove_pad(), which
fires a pad-removed signal.  So I think we have the mechanism, but it
has most likely never been tested, since no element uses it.  Perhaps
you're just saying that elements should remove their automatic pads
when going to NULL (READY?), or upon receiving new media.
Comment 2 Ronald Bultje 2003-09-30 08:09:21 UTC
READY, since that's when the media state is reset (convention). And
also on a discont with new_media event.
Comment 3 Benjamin Otte (Company) 2003-09-30 10:52:53 UTC
Well, that goes for SOMETIMES pads, but doesn't make sense for 
REQUEST pads. 
I think REQUEST pads should probably be removed automatically 
whenever you unlink the pad. Though that would mean that you could 
not relink a REQUEST pad. I'm not really sure.

Let me try to find a way to set this in stone (as in documentation):
GST_PAD_ALWAYS: These pads are always available. They are available 
after the element is created an they will not be removed until the 
element is disposed.
GST_PAD_SOMETIMES: These pads are created and destroyed by the 
element. You can connect to the "new-pad" and "pad-removed" signals 
to find out about this. Note: even linked sometimes pads (FIXME: this 
sounds crappy) may go away forcing unlinking with its peer pad. 
Please make sure your code reflects that.
GST_PAD_REQUEST: Pads of this type are automatically removed when you 
unlink this pad. If you want to relink, you have to request another 
pad. 

A possible addition to request pads: "It is not allowed to have 
unlinked request pads in an iterating pipeline." This would force 
coders to actually connect newly acquired request pads.

Another way to get around this is to change the API to not allow 
getting request pads but automatically create request pads for 
example via
gst_element_request_link (element_to_link_to, pad_to_link_to, 
pad_template_to_use_or_NULL)
thought that would make it somewhat harder to link 2 request pads.
Comment 4 Ronald Bultje 2003-09-30 11:06:43 UTC
I'd say it differently. For ALWAYS/SOMETIMES, you're correct, the
elements owns them, controls them and destroys (or, rather, unrefs) them.

For REQUEST, however, I'd say that the requester (application) owns
the pad, not the element. So the application must also unref it when
it's done. This also means that for each request pad, the element gets
an additional ref() and the element is unref()ed when the pad is
destroyed.

Does that make sense?
Comment 5 Benjamin Otte (Company) 2003-09-30 13:41:28 UTC
I don't like that idea, because most of the time the app doesn't want 
to know that it just linked request pads and now is responsible for 
them. gst_element_link makes use of request pads for example.

But after thinking a bit more about it I think it makes sense to sink 
a request pad when it is linked and make the element not hold a 
reference to it. That way the only reference is held by the peer pad 
(unless the application refs the pad before) and the pad is removed 
automatically upon unlinking.

So in short:
ALWAYS: element/peerpad hold references.
SOMETIMES: element/peerpad hold references, element might unlink and 
remove.
REQUEST: peerpad holds reference, element does not.
Comment 6 Ronald Bultje 2003-09-30 13:56:38 UTC
Sounds good for a default. If the application wants a reference to a
pad, GObject is a good help. ;).

Someone want to fix all elements and the core to do this? :).
Comment 7 Ronald Bultje 2004-10-29 11:59:41 UTC
*** Bug 156380 has been marked as a duplicate of this bug. ***
Comment 8 Wim Taymans 2004-11-02 15:17:23 UTC
Request pads are requested by the app and the app is responsible for releasing
them using gst_element_release_request_pad. This of course conflicts with the
automatic linking functions, which hide what you are really doing.
Comment 9 Andy Wingo 2005-07-14 16:16:50 UTC
If an automatic linking functions (i.e. gst_element_link_pads()) request a pad,
they should connect to ::unlinked on the request pad. The onus (I just said
onus) is on the immediate caller of gst_element_request_pad to arrange to
release the request pad.

Parent objects always have references to their children. Thus removing the
application's reference is insufficient to dispose the pad. release_request_pad
must be used as Wim said. Leaving bug open until docs are updated
(docs/manual/basics-pads.xml) and the gstutils functions arrange to release the
request pad (preferably accompanied by test suites). Changing name to reflect
nature of bug. 
Comment 10 Benjamin Otte (Company) 2005-07-15 11:43:24 UTC
I don't like the policy of requiring manual removal of a pad.
If a pad is not used, it should disappear _automatically_ in the default setup.
Otherwise it's just confusing developers.
As evidence for this I present the linking functions.

And why is it so important that the parent holds a reference?
Comment 11 Jan Schmidt 2006-05-06 21:28:28 UTC
What are we going to do about this bug? It'd be nice to close it at some point.
Comment 12 Tim-Philipp Müller 2012-09-28 18:11:13 UTC
I think this is fixed now in 1.0:

 commit 9048b4dc2af3d80ff696280565143975da80d017
 Author: David Schleef <ds@schleef.org>
 Date:   Sat Dec 4 18:53:55 2010 -0800

    element: call ->release_pad() to clean up pad

    https://bugzilla.gnome.org/show_bug.cgi?id=636011
    https://bugzilla.gnome.org/show_bug.cgi?id=402562