Those will cause us to renegotiate at the next aggregate cycle,
and while at that point we may decide to reconfigure upstream
branches (in practice we don't as this is inherently racy,
and that's the reason why mixer subclasses perform conversion
internally), we certainly don't want to just forward the event
willy-nilly to all our sinkpads.
An actual issue this is fixing is when caps downstream of a
compositor are changed at every samples-selected signal emission,
for the purpose of interpolating the output geometry, and the
compositor has a non-zero latency, the reconfigure events were
forwarded to basesrc, which triggered an allocation query, which
in turn caused aggregator to have to drain (thus not being able
to queue <latency> frames), leading to disastrous effects
(choppy output as compositor couldn't consume frames fast enough,
the higher the latency the choppier the output)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1464>
When detecting the remote time has been reset which may occur if remote
device providing the clock server has been power reset, then clock is
no longer synced. Setting clock state will trigger a signal to client
informing on sync lost making it possibility to take appropriate action.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/975>
gst_base_parse_reset() does not reset data_bytecount to 0, so
gst_base_parse_update_bitrates() uses a wrong value to calculate
the average bitrate on subsequent pipeline starts. This leads to an
excessive amount of "tag" events being pushed. These events include
very high "bitrate" values that diminish over time, and are produced
until the average bitrate is back to sane values.
Fixes#840
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1228>
An inactive pad is a pad which, in live mode, hasn't yet received
a first buffer, but has been waited on at least once.
Exposing API to support this behaviour allows users of aggregator
subclasses to request pads, and not start pushing data on those
immediately, while avoiding systematic timeouts.
Subclasses must check in explicitly to this behavior, most likely
by exposing a user-facing property, and must check whether a pad
needs ignoring when aggregating. That is because by design,
aggregator subclasses don't get a list of "ready" pads, but instead
directly iterate element->sinkpads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/867>
Introduces a `libraries` variable that contains all libraries in a
list with the following format:
``` meson
libraries = [
[pkg_name, {
'lib': library_object
'gir': [ {full gir definition in a dict } ]
],
....
]
```
It therefore refactors the way we build the gir so that we can reuse the
same information to build them against 'gstreamer-full' in gst-build
when linking statically
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1093>
