GNOME Bugzilla – Bug 123237
REQUEST pad lifecycle needs documentation, element utils need corresponding updates
Last modified: 2012-09-28 18:11:13 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.
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.
READY, since that's when the media state is reset (convention). And also on a discont with new_media event.
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.
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?
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.
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? :).
*** Bug 156380 has been marked as a duplicate of this bug. ***
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.
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.
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?
What are we going to do about this bug? It'd be nice to close it at some point.
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