Better now than later in the cycle. These might come in handy:
sed -i -e 's/GstProbeReturn/GstPadProbeReturn/g' `git grep GstProbeReturn | sed -e 's/:.*//' | sort -u`
sed -i -e 's/GST_PROBE_/GST_PAD_PROBE_/g' `git grep GST_PROBE_ | sed -e 's/:.*//' | sort -u`
sed -i -e 's/GstProbeType/GstPadProbeType/g' `git grep GstProbeType | sed -e 's/:.*//' | sort -u`
No one uses this or should ever need to use it, since
the size is architecture-specific anyway. If normal
integers don't do, one should use 64-bit integers.
It's not really used outside of core at all, and has
serious namespace issues. If anyone feels the need to
revive this one, please use a less generic name space.
API: deprecate gst_filter_run()
API: deprecate GstFilterFunc
It's only used internally anyway and the helper struct
has namespace issues.
API: deprecated gst_plugin_feature_type_name_filter()
API: deprecated GstTypeNameData
Hide the fact that it's just a GstStructure from the API. We
may want to change this in future (e.g. to add refcounting).
Also, it caused problems for bindings (though that's mostly
the way we typedefed it to GstStructure).
We never get a tag name quark from a caller, it's always a
string, from which we'll try to look up our tag info in the
hash table, so change the hash table key from quark to string.
Avoids a bunch of pointless string => quark lookup in the
global quark table. We need to do an extra string => quark
conversion now when we copy a taglist, but in that case we're
in a slow path anyway.
This will make sure we spawn a new plugin scanner helper for each plugin
to be introspected, which helps with making sure we don't load too many
shared objects (libs, plugins) at the same time on systems where there
is a hard limit like on Android.
A better version might re-use the scanner for up to N times, though
it's not clear whether that would actually improve things dramatically.
https://bugzilla.gnome.org/show_bug.cgi?id=662091
The second caps ownership is transfered, no need to require it to
be writable from the caller function. Instead, _append and _merge
make it writable on their own.
Discovered because of an assertion on encoding-profile.c in
_get_input_caps using _merge but not passing writable caps.
Returning a newly allocated string makes no sense. It's unexpected for a
getter, and also this behaves differently in 0.10, so it would make future
merges harder.
Except for these two places here in core which were updated for the new
semantic, the return value is getting leaked all over the place.
