GNOME Bugzilla – Bug 740322
Proposal of smart-properties
Last modified: 2017-07-14 15:30:28 UTC
Usually, setting properties are stateless except for GST_PARAM_MUTABLE_* attributes. Special purpose properties need to be shared from source to sink element. This is a proposal to solve the problems; * Avoid to call repeatedly childproxy to set same properties into multiple elements * Assure that given properties exist when sink pad is connected To help understand this proposal, please, consider next scenario. Let's assume that there is thumbnail-mode. I know, extracting thumbnail from gstreamer isn't efficient way, but we can. If the mode is enabled, * demuxer should not create audio/subtitle pads. * decoder should decode as soon as possible (e.g, only I-frame can be acceptable) * render should be optimised to send its raw buffer to the thumbnail extractor With this feature, there are several restrictions when setting "thumbnail-mode" property. * setting the property is valid only before transiting element state. setting the property to demux in playing state is meaningless because it would already have audio/subtitle pads * To set the property into demux, decoder, and renderer, we have to know exact element name of them if we use childproxy. it causes another burden to get names if we are using autoplugging like playbin To solve these problem, we defined "smart-properties" APIs. We made that * basesrc can accept "smart-properties" as GstStructure * any element can get the property by UPSTREAM_EVENT if its sinkpad is connected. A flaw is that it doesn't work if source element is not a child class of basesrc.
Created attachment 290922 [details] [review] proposal of smart-properties, first attachment
The difficulties you face might also be symptoms for that decodebin is not the perfect api to get thumbnails. Wouldn't it make more sense to have a thumbnailbin (previewbin)?
Couple of comments: - there's GstContext now, I think it could be used in similar ways - there are GST_SEEK_FLAG_TRICKMODE, GST_SEEK_FLAG_TRICKMODE_KEY_UNITS and GST_SEEK_FLAG_TRICKMODE_NO_AUDIO seek flags now - also see bug #578933 for a generic "deep-element-added" signal or an "element-setup" signal on playbin/decodebin - also see bug #696952 for the ability to set up the 'initial seek' > we have to know exact element name of them if we use childproxy. - This is surely something that could be fixed in GstChildProxy ? So in summary, I think this can probably be done - either generically via GstContext (and adding custom code in your demuxer, just like you would with your proposal, if I understand correctly) or for your specific by setting up the initial seek somehow with trick modes so that only I-frames are output on the video pads. Or perhaps GstChildProxy should be improved to not require you to know the exact name.
Comment on attachment 290922 [details] [review] proposal of smart-properties, first attachment Padding needs to be fixed up when adding fields to the public structure. (Didn't review in detail, just noticed this).
> > > we have to know exact element name of them if we use childproxy. > > - This is surely something that could be fixed in GstChildProxy ? Since GstObject does not impose any restrictions on names (like we have for GObject properties) we cannot use globs here unfortunately. gst_child_proxy_set(root, "elem*::prop", value, NULL); Likewise we can't introduce some syntax to select elements by class or the like. Maybe we can do a FIXME-2.0 here. Maybe we can still do it, but WARN if someone actually uses '*?' chars in the name (WARN in gst_object_set_name). The glob should have some 'deep' match e.g. gst_child_proxy_set(root, "**::prop", value, NULL); as in set any 'prop' of elements below root. Regarding setting properties on elements created by autoplugging. We have a mechanism for that in parse_launch. When a child_property does not yet exist, in will add signal handlers to look for new children. We could extract the code from parse launch and move it to the child_proxy as a generic helper. It will need some special care to recheck deep globs for new child elements.
Stefan, surely one could add a new function to set things by type name or with globs if one wanted to? I also think it's fine to not worry too much about backwards compatibility for GstObject names that contain '*' or :: or {} or wahtever.
Then, in summary, GstContext provides more elegant way to share information than smartproperties. but, more syntax for child_proxy to set property *deeply* is still required. Am I right?
Yes, IMHO anyway. Let's close this. Please feel free to open new bugs about child proxy improvements if you have a patch for those.