In some cases, probes might want to handle the buffer/event/query
themselves and stop the data from travelling further downstream.
While this was somewhat possible with buffer/events and using
GST_PROBE_DROP, it was not applicable to queries, and would result
in the query failing.
With this new GST_PROBE_HANDLED value, the buffer/event/query will
be considered as successfully handled, will not be pushed further
and the appropriate return value (TRUE or GST_FLOW_OK) will be returned
This also allows probes to return a non-default GstFlowReturn when dealing
with buffer push. This can be done by setting the
GST_PAD_PROBE_INFO_FLOW_RETURN() field accordingly
https://bugzilla.gnome.org/show_bug.cgi?id=748643
It will make the default accept-caps handler use the pad template
caps instead of the query-caps result to check if the caps is
acceptable. This is aligned with what the design docs says the
accept-caps should do (be non-recursive) and should be faster. It
is *not* enabled by default, though.
API: GST_PAD_FLAG_ACCEPT_TEMPLATE
API: GST_PAD_IS_ACCEPT_TEMPLATE
API: GST_PAD_SET_ACCEPT_TEMPLATE
API: GST_PAD_UNSET_ACCEPT_TEMPLATE
https://bugzilla.gnome.org/show_bug.cgi?id=753623
If no date and only a time is given in gst_date_time_new_from_iso8601_string(),
assume that it is "today" and try to parse the time-only string. "Today" is
assumed to be in the timezone provided by the user (if any), otherwise Z -
just like the behavior of the existing code.
https://bugzilla.gnome.org/show_bug.cgi?id=753455
Add methods to add/remove the providers that should be hidden by this
provider. Also make a method to get a list of hidden providers.
This makes it possible to have multiple systems monitor the same devices
and remove duplicates.
Add a property to see all devices, even duplicate ones from hidden
providers.
The previous implementation was doing a direct call to the peer pad,
which resulted in query probes never being called on the original pad.
Instead of that, get the peer pad caps by using gst_pad_peer_query()
which will call probes in the expected fashion.
While calling gst_value_deserialize_sample, if there is a failure
after caps is ref'ed, then caps is getting leaked. Hence checking for
caps in fail: goto condition and unref'ing it
https://bugzilla.gnome.org/show_bug.cgi?id=753338
When running gst_registry_scan_plugin_file we were losing the
information about the registry being loaded and ended up adding the
plugin to the default registry which was not correct.
https://bugzilla.gnome.org/show_bug.cgi?id=752662
In case there is an IDLE probe fired from gst_pad_push_data and it
doesn't return GST_FLOW_OK, the code jumps to the probe_stopped
label which tries to unref the data object. However, at this point
the data object belongs downstream and must not be touched.
By setting data = NULL, the code skips this unref.
https://bugzilla.gnome.org//show_bug.cgi?id=753151
Release the monitor lock when calling the provider start/stop methods.
Because we release the lock now, We need to make sure we check the
cookie again and keep track of started and removed providers.
The deviceproviders are added to the array sorted by their rank. Make
sure we keep this ordering when removing a provider.
We use _prepend to collect the devices, use g_list_reverse to get the
devices in the right order; sorted by rank and in the same order as
returned by the provider.
The check for the presence of the parent in the presence of
the NEED_PARENT flag was missing for the chain function. Also keep
a ref on the parent in case the pad is removed mid-chain.
Don't copy memory metas if we only copied part of the buffer, didn't
copy memories or merged memories. In all these cases the memory
structure has changed and the memory meta becomes meaningless.
https://bugzilla.gnome.org/show_bug.cgi?id=751712
Do not ignore the caps argument when requesting a pad by template.
This is particularly harmful when the pad caps query by default
returns ANY so it will match the first template instead of the
one that actually intersects with the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=751235
