If no providers for a particular class could be found, then removing unmatched
filters would cause all devices to be returned instead which is not at all what
the user intended. We still return 0 for unmatched filters.
Instead of re-sending sticky events over and over to a not-linked
pad, mark them as sent the first time. If the not-linked came from
downstream, it already received the events. If the pad is actually
not-linked, the sticky events will be rescheduled when the
pad is linked anyway.
Updated gst_segment_position_from_stream_time and gst_segment_to_stream_time to reflect correct calculations for the case when the applied rate is negative.
Pasting from design docs:
===============================
Stream time is calculated using the buffer times and the preceding SEGMENT
event as follows:
stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time
For negative rates, B.timestamp will go backwards from S.stop to S.start,
making the stream time go backwards.
===============================
Therefore, the calculation for applied_rate < 0 should be:
stream_time = (S.stop - B.timestamp) * ABS (S.applied_rate) + S.time
and the reverse:
B.timestamp = S.stop - (stream_time - S.time) / ABS (S.applied_rate)
https://bugzilla.gnome.org/show_bug.cgi?id=756810
An ASYNC READY->PAUSED might have failed without the bin code noticing during
the state change, in which case we will never get PAUSED->READY and would leak
messages.
https://bugzilla.gnome.org/show_bug.cgi?id=756611
This fixes a race where a state change may return failure if it has
request pads that are deactivated and removed (and thus have no
parent) at the same time as the element changes state and (de)activates
its pads.
https://bugzilla.gnome.org/show_bug.cgi?id=755342
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.
