GNOME Bugzilla – Bug 750079
registry: add factory for automatic dynamic caps enum/flags types loading
Last modified: 2016-11-02 00:50:16 UTC
Here's a patch for an idea to allow new types to be added to caps and pad templates. In the past, it's been a problem that you can only use types from GLib or GStreamer core sensibly in caps (especially pad templates), because they need to be deserialised from the registry. This patch adds a new registry feature GstDynamicTypeFactory, that allows for registering a GType by name. If the name is encountered in a caps string/structure during deserialisation, it triggers loading a plugin to register the GType. I'm using this in the stereoscopic branch to allow registration of the 'multiview-flags' caps field, which is a GstVideoMultiviewFlagsSet derived from a GstFlagSet. Registering the type allows serialising/deserialising a human-readable version of the flags, instead of just numeric values.
Created attachment 304211 [details] [review] dynamic types: Implement dynamic types in the registry Implement GstDynamicTypeFactory as a new registry feature. GstDynamicTypeFactory provides a way of registering a GType into the registry, such that it will be registered as a dynamic type when the registry is loaded, and then automatically loaded if the type is needed during caps parsing. This allows using non-core types in pad templates, by loading a registry feature to create the GType on the fly.
Created attachment 304212 [details] [review] pbtypes: Add a stub plugin that owns the plugins-base dynamic types
Created attachment 335186 [details] [review] dynamic types: Implement dynamic types in the registry Implement GstDynamicTypeFactory as a new registry feature. GstDynamicTypeFactory provides a way of registering a GType into the registry, such that it will be registered as a dynamic type when the registry is loaded, and then automatically loaded if the type is needed during caps parsing. This allows using non-core types in pad templates, by loading a registry feature to create the GType on the fly.
Comment on attachment 335186 [details] [review] dynamic types: Implement dynamic types in the registry Nice!
Comment on attachment 304212 [details] [review] pbtypes: Add a stub plugin that owns the plugins-base dynamic types Wonder if it wouldn't make sense to add these types instead to one of the basic elements, like videoconvert/audioconvert or such, then only the audio/video-specific libs are loaded. But then I guess it doesn't matter and we can always change it later. Just seems silly to do yet another mini-plugin for this :)
Adding to an existing plugin could work too, they just need to be somewhere. Hopefully there'll be more in the future.
This feels a bit overkill to potentially load a bunch of plugins to just register some enum/flag types. Could we instead put the types into the registry itself and have the registry loader do the registration? Do we have any other kind of GType that we may want to register ? If you want to keep this API, can you rename it, dynamic type makes me think of g_type_register_dynamic() which is somethign different.
(In reply to Olivier Crête from comment #7) > This feels a bit overkill to potentially load a bunch of plugins to just > register some enum/flag types. Could we instead put the types into the > registry itself and have the registry loader do the registration? Do we have > any other kind of GType that we may want to register ? The idea was to have at most 1 extra plugin per module that needs extra types. Really though, I think it's likely that it'd just be this gst-plugins-base one, and Tim's suggestion to register the types from one of the existing plugins that's likely to be loaded anyway also works for me - videoconvert, for example. How would you update them if they change? Registry features need to belong to a plugin. It's a lot more work for almost no gain. > If you want to keep this API, can you rename it, dynamic type makes me think > of g_type_register_dynamic() which is somethign different. Feel free to suggest a different name.
What should happen here now?
I think it's fine and should go in. Don't think it's overkill. Waiting on Olivier to suggest a better name for the API he didn't like. If no suggestion is coming forward we should just go with what we have IMO. I don't know if it's really confusing because most people won't even have heard of that GType API anyway, and few will ever look at this one :)
Pushed as #e1dc60 (core) and #2c786e (-base)