GNOME Bugzilla – Bug 757925
bufferpool config: function to remove an option in the config
Last modified: 2018-11-03 12:30:44 UTC
The use case I have for this is if an element wants to override/perform the creation of a meta on the buffer. A simple solution of using gst_buffer_foreach_meta(); gst_buffer_remove_meta() will fail to remove any locked buffers that a bufferpool adds to the buffer. This makes it optional and possible for the meta to not appear on the buffer in the first place.
Created attachment 315224 [details] [review] bufferpool: add function to remove an option from a pool config
Review of attachment 315224 [details] [review]: In certain scenario, we force certain options by pre-configuring the pool (in propose allocation). This way, we don't have to check if we receive buffers from that pool. Shall be simply ignore the removal of such option during activation of those pool, or shall be add a way to prevent removal ? p.s. Typo in the commit message, there is no S at the end of the method name
Review of attachment 315224 [details] [review]: ::: gst/gstbufferpool.c @@ +892,3 @@ + * not contain the specified option, @config is not modified. + * + * The supported options by @pool can be retrieved with gst_buffer_pool_get_options(). Since: 1.8 @@ +901,3 @@ + guint i, len; + + g_return_if_fail (config != NULL); Maybe should also get a g_return_if_fail() to check if the structure is writable, but then we also don't do that elsewhere.
(In reply to Nicolas Dufresne (stormer) from comment #2) > Review of attachment 315224 [details] [review] [review]: > > In certain scenario, we force certain options by pre-configuring the pool > (in propose allocation). This way, we don't have to check if we receive > buffers from that pool. Shall be simply ignore the removal of such option > during activation of those pool, or shall be add a way to prevent removal ? Hmm, that's a bit non-backward compatible, but the pools maybe review the options, update the config and return false to the set_config call to signal that the configuration was adapted to the pool restrictions.
What shall we do with this?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/138.