Some applications are requesting the same pad name multiple times
and the behaviour is undefined and different from element to element
but we don't want to break applications that work just fine.
In 0.11 this check should be an assertion again, although elements
have to do manual checking if the pad already exists again because
it can't be done in a threadsafe way here.
This commit changes the request pad behaviour for plugins and applications.
Reopens Bug #402562
The proper fix for that bug is to keep track of created request pads.
This reverts commit a5e44ffffa.
gstelement.c: In function ‘gst_element_get_request_pad’:
gstelement.c:1052:18: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable]
https://bugzilla.gnome.org/show_bug.cgi?id=640850
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
Add a GstStructure to GstElementClass and GstElementFactory. Add setters/getter.
Handle it in the registry code. Print items in gst-inspect.
Fixes#396774.
API: gst_element_class_set_meta_data(), gst_element_factory_get_meta_data_detail()
Since everything GstXML related has been deprecated, we can now skip the
libxml includes from the public headers when GST_DISABLE_DEPRECATED is
defined.
See #463435.
Pipeline serialisation to and from XML is horribly broken for all
but the most simple use cases, and will likely never be fixed.
Make sure everyone playing around with these tools is aware of
this, to avoid frustration. See countless bug reports in bugzilla.
Fixes bug #622685.
A pad is 'negotiable' when its container element is in a state greater
than GST_STATE_READY
API:gst_pad_is_negotiable
API:gst_pad_set_negotiable
API:GST_PAD_NEGOTIABLE
https://bugzilla.gnome.org/show_bug.cgi?id=618644
Use gst_element_class_set_details_simple() instead. If you want to
convert automatically, here's a script:
for file in `git grep -l GstElementDetails`; do
sed -i -n -r '
1h
1!H
$ {
g
s/((\/\*[^\n]*\*\/)?\n)*[^\n]*GstElementDetails .* =\s*GST_ELEMENT_DETAILS\s*\((\"[^\"]*\",\s*\"[^\"]*\",\s*\"[^\"]*\",\s*(\"[^\"]*\"\s*)*)\);\n*(.*)gst_element_class_set_details \(([^,]*),\s*[^)]*\)/\n\n\5gst_element_class_set_details_simple (\6, \3)/
s/((\/\*[^\n]*\*\/)?\n)*[^\n]*GstElementDetails .* =\s*\{\s*(\"[^\"]*\",\s*\"[^\"]*\",\s*\"[^\"]*\",\s*(\"[^\"]*\"\s*)*)\};\n*(.*)gst_element_class_set_details \(([^,]*),\s*[^)]*\)/\n\n\5gst_element_class_set_details_simple (\6, \3)/
p
}' $file
~/gst/gstreamer/tools/gst-indent $file
done
There's not much point in using GST_DEBUG_FUNCPTR with GObject
virtual functions such as get_property, set_propery, finalize and
dispose, since they'll never be used by anyone anyway. Saves a
few bytes and possibly a tenth of a polar bear.
It is not too obvious that getting and releasing request pads is not entierly
symetrical regarding to the pad refcount. Add a note about that to the docs.
This might deserve a FIXME-0.11 too.
The first time one calls gst_element_factory_make(), gst recreates the plugin
feature and the element factory. As a side effect we ref the class to fill
in detail we already have filled from the registry cache. This patch changes
the behaviour to just update the existing entries. The factory is now attached
to the type and set in gst_element_base_class_init().
