[gst-devel] requested pads

Andy Wingo wingo at pobox.com
Fri Jan 30 06:45:01 CET 2004


Hi Julien,

On Sat, 2004-01-24 at 15:08, Julien MOUTTE wrote:
> It seems that nobody is currently implementing that method in elements
> supporting requested pads.

Check the sndfile plugin. As it only supports multi-pad float input,
it's not being used be anyone really (other than me of course ;), so
perhaps that's why you didn't notice.

> Moreover when unlinking elements like tee for example pads are just
> leaked.

Hmm... This is a problem.

> Why not implementing in gst_pad_unlink something that would
> gst_element_release_request_pad if the pad was requested ?

Request pads are used a lot in multi-pad float pipelines -- that's
really the only time, besides adder, that I've seen fit to use them. In
fact, they've been over-used by me, to implement requesting different
Jack "port names" for different pads. Of course that data has to be
stored for each pad, so I hacked by putting it in the request pad name.
Also, I don't know if it still works this way, but you used to (in
theory) be able to request explicit alsa channels via the pad name.

I digress. I gave these examples because I wanted to show that
requesting a pad, on some elements is requesting more than just a pad.
For instance, it could change the format of a sndfile output, or
changing the caps format for float2int, or something. It would be good
to avoid unnecessary releases and re-requests in the case where you are
just replugging to the same sink.

But yes, your problem is valid. However, I don't think refcounts are the
way to go on this one, because the parent of the pad should be the only
one to hold a ref on the pad (via gst_object_set_parent). I think that
the release_pad interface is the correct solution, because it releases
the implicit reference on the pad created by request_pad.

Therefore, any plugin which implements request_pad should also implement
release_pad. Then it is the responsibility of the code that calls
get_request_pad to do the releasing.

Perhaps we can assist the app writer (this applies equally to gst-parse)
by modifying gst_element_get_request_pad to take an additional boolean
argument, release_on_unlink, that will attach to ::unlink (or whatever
it's called :) to call release_pad. But it's too late IMO for 0.8; this
convenience can be done by app writers themselves.

Best regards,

-- 
Andy Wingo <wingo at pobox.com>




More information about the gstreamer-devel mailing list