GNOME Bugzilla – Bug 637300
[API] request pad based on caps
Last modified: 2011-01-05 18:47:57 UTC
We should add new API to core to make requesting pads based on caps possible (dynamically). The normal way doesn't work for encodebin, because it has quasi-dynamic pad templates, that depend on the configured encoding profile, but pad templates can't actually be dynamic and so in encodebin's case they only have ANY caps on them, which means that code that wants to create a request pad for certain caps can't just iterate the templates and intersect to find the right template. Wim suggested just creating a new template and setting the desired caps on that and passing that to the request pad vfunc implementation, but I don't know of any request_pad_new implementations that expect such behaviour and don't assume that the pad template is one of the ones it set up before. The easiest way would be to just create a new function/vfunc with an additional GstCaps * argument (and maybe deprecate the old one). Alternatively, one could go for just adding a new func/vfunc with direction+caps, since template+name are most likely not of interest in this use case.
Created attachment 176760 [details] [review] GstElement: Add a more flexible way to get request pads. The new request_new_pad_full vmethod is the exact same signature as the regular one, except that it can be provided pad templates that weren't registered by the element. This is useful for being able to request pads in a more flexible way, especially when the element can provide pads whose caps depend on runtime configuration and therefore can't provide pre-registered pad templates. API: GstElement::request_new_pad_full API: gst_element_request_pad_by_caps
Looks like a good and straight-forward approach to me. Two questions: - should gst_element_get_request_pad_by_caps() implement a fallback, e.g. using gst_element_get_compatible_pad_template()? (would be nice, imho) - do we want to allow passing a NULL name to gst_element_get_request_pad_by_caps()?
(In reply to comment #2) > Looks like a good and straight-forward approach to me. > > Two questions: > > - should gst_element_get_request_pad_by_caps() > implement a fallback, e.g. using > gst_element_get_compatible_pad_template()? > (would be nice, imho) I considered it... and then realized how ugly the 'regular' gst_element_get_request_pad is so decided against it. > > - do we want to allow passing a NULL name to > gst_element_get_request_pad_by_caps()? Yes !
Review of attachment 176760 [details] [review]: ::: gst/gstelement.c @@ +1106,3 @@ + + /* If the element class implements the request_new_pad_full() vmethod, + * use that. */ the comment would suggest that we can do some fallback, if the class does not implement request_new_pad_full(). Can we? @@ -1077,0 +1079,40 @@ + * gst_element_get_request_pad_by_caps: + * @element: a #GstElement to find a request pad of. + * @direction: the direction of the pad to request ... 37 more ... leftover goto? ::: gst/gstelement.h @@ +669,3 @@ + /* Virtual method for subclasses (additions) */ + GstPad* (*request_new_pad_full) (GstElement *element, GstPadTemplate *templ, const gchar* name); + Should there be a FIXME-0.11: comment to drop it and move the new behavior to the old method?
Review of attachment 176760 [details] [review]: Retry comment, as splinter screwed it a bit the last time. ::: gst/gstelement.c @@ +1117,3 @@ + + goto beach; + } left over goto?
> > - should gst_element_get_request_pad_by_caps() > > implement a fallback, e.g. using > > gst_element_get_compatible_pad_template()? > > (would be nice, imho) > > I considered it... and then realized how ugly the 'regular' > gst_element_get_request_pad is so decided against it. I don't understand the logic in this sentence at all - are we talking about the same thing? :) I would like for this to work: caps = gst_caps_new ("audio/x-flac",..., NULL); pad = gst_element_get_request_pad_by_caps (mux, caps); even if the muxer doesn't implement the new vfunc yet.
> pad = gst_element_get_request_pad_by_caps (mux, caps); Or rather: pad = gst_element_get_request_pad_by_caps (mux, GST_PAD_SINK, caps, NULL);
(In reply to comment #4) > Review of attachment 176760 [details] [review]: > > ::: gst/gstelement.c > @@ +1106,3 @@ > + > + /* If the element class implements the request_new_pad_full() vmethod, > + * use that. */ > > the comment would suggest that we can do some fallback, if the class does not > implement request_new_pad_full(). Can we? It will use the 'regular' request_new_pad method otherwise.
Created attachment 176821 [details] [review] GstElement: Add a more flexible way to get request pads. The new request_new_pad_full vmethod is the exact same signature as the regular one, except that it can be provided pad templates that weren't registered by the element. This is useful for being able to request pads in a more flexible way, especially when the element can provide pads whose caps depend on runtime configuration and therefore can't provide pre-registered pad templates. API: GstElement::request_new_pad_full API: gst_element_request_pad_by_caps
30-12-2010 11:05h tim : wtay, any more thoughts on the dynamic request pad API? https://bugzilla.gnome.org/show_bug.cgi?id=637300 tim : you said you changed your mind and prefer another version now? (Which one was that exactly?) wtay : (element, templ, name, caps) wtay : an element can then use templ to find out what type of pad (by directly comparing the pointers) wtay : (like it is now) wtay : and then create an instance of name and caps tim : is it allowed to pass NULL template and NULL name then? wtay : I would say no wtay : you can pass NULL as the name tim : ok tim : mind if I paste this into the bug? wtay : you can put NULL for caps wtay : but you always need to provide a templ wtay : (else you don't know the direction) tim : right wtay : the current gst_element_get_request_pad() is broken wtay : it does not let you specify the template wtay : it does some crazy stuff to find a template based on what name you give.. tim : right tim : from a user point of view finding + passing templates is rather inconvenient though, but that could be solved via utility api I guess wtay : a convenience API would be _get_request_pad_full (element, template_name, name, caps) wtay : shortcut for templ = _get_template (element, template_name); _get_request_pad (element, templ, name, caps)
Created attachment 177500 [details] [review] GstElement: Add a more flexible way to get request pads. The new request_new_pad_full vmethod provides an additional caps field, which allows elements to take better decision process. In addition, add a _full variant of gst_element_request_pad() to allow developers to be able to specify which pad template they want a pad of. This is useful for being able to request pads in a more flexible way, especially when the element can provide pads whose caps depend on runtime configuration and therefore can't provide pre-registered pad templates. API: GstElement::request_new_pad_full API: gst_element_request_pad_full
Created attachment 177599 [details] [review] GstElement: Add a more flexible way to get request pads. The new request_new_pad_full vmethod provides an additional caps field, which allows elements to take better decision process. Also, add a gst_element_request_pad() function to allow developers to be able to specify which pad template they want a pad of. Convert gstutils to use that new method instead of the old one when more efficient. This is useful for being able to request pads in a more flexible way, especially when the element can provide pads whose caps depend on runtime configuration and therefore can't provide pre-registered pad templates. API: GstElement::request_new_pad_full API: gst_element_request_pad
commit 04ebbc9f5ad71322b7df91229f1a43e6bc218aca Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Dec 20 13:30:43 2010 +0100 GstElement: Add a more flexible way to get request pads. The new request_new_pad_full vmethod provides an additional caps field, which allows elements to take better decision process. Also, add a gst_element_request_pad() function to allow developers to be able to specify which pad template they want a pad of. Convert gstutils to use that new method instead of the old one when more efficient. This is useful for being able to request pads in a more flexible way, especially when the element can provide pads whose caps depend on runtime configuration and therefore can't provide pre-registered pad templates. API: GstElement::request_new_pad_full API: gst_element_request_pad https://bugzilla.gnome.org/show_bug.cgi?id=637300