Instead of having each tracer implement its own parameter parsing,
centralize the handling in the tracer subsystem using GstStructure.
This simplifies tracer implementations and provides a consistent way
to handle properties.
It also allows for much better documentation by forcing tracer object
to expose properties
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8086>
In the case where the bufferlist is writable, send the
buffers immediately without adding to the refcount. This
allows writable buffers to maintain their writability, even
without implementing a chain_list function on the element.
Adds a test to verify this property, where a writable list
maintains refcount 1, but a readonly list increases it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7894>
This commit adds a Find Module implementing the necessary logic to link
against GStreamer, while implementing some extra bits to enhance the
compatibility.
The first addition is the `mobile` target, which implements the
monolithic `gstreamer_android` library, and which here gains
compatibility with Apple's operating systems.
The second addition is the handling of the basic GStreamer libraries as
`--whole-archive` when statically linked, which was ported from the
ndk-build project in Cerbero. This is not easy to do, as CMake suffers
from several issues that impede its proper usage of pkg-config:
- It cannot differentiate between system/compiler specific libraries
e.g. `-lm`, `-ldl`, but especially `-framework Cocoa`.
- It does not support `--whole-archive` natively until 3.27
- It attempts to reorder flags blindly by separating them with spaces,
thus requiring the use of `-Wl,` wrapping or (in the case of Apple
frameworks) manual framework lookup
The third addition is the port of the Fontconfig and ca-certificates
bundling logic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6881>
We do not own any ref to queries when running them.
If we end up processing the query from the streaming thread, it means that it was
a serialized query, and the query is being waited to be processed on the sinkpad
streaming thread, thread which owns the reference.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7767>
This is documented as:
> you can query how many buffers are queued by reading the
> #gstqueue:current-level-buffers property. you can track changes
> by connecting to the notify::current-level-buffers signal (which
> like all signals will be emitted from the streaming thread). the same
> applies to the #gstqueue:current-level-time and
> #gstqueue:current-level-bytes properties.
... but was not implemented.
This also respects the `notify::silent` property for the notify signals
to be less intrusive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7486>
When force-live is TRUE, aggregator will correctly change its state with
NO_PREROLL, but unless something upstream is live did not previously set
live to TRUE on the latency query.
Fix this by or'ing force_live into the result.
Also improve debug
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7718>
This reverts commit 779e715b6cee4f7793c43a0e78c6106ab66f1032.
Since the introduced corrupt clock state for when discovering a time
server restart, this resulted in previous similar check as done in
this patch became ignored/jumped over (in case of the corrupt state
has been noticed).
Reference: df41d11a7d7f844e593a10f6a6a0858333fbf7ec
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
Clients that already gotten a signal for synced clock, may rely on
getting the same when marked as corrupted to take appropriate action. So
send clock signal indicating no sync at identified corrupted state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
FLUSH_STOP is meant to clear the flushing state of pads and elements
downstream, not to process data. Hence, a FLUSH_STOP should not
propagate sticky events. This is also consistent with how flushes are a
special case for probes.
Currently this is almost always the case, since a FLUSH_STOP is
__usually__ preceded by a FLUSH_START, and events (sticky or not) are
discarded while a pad has the FLUSHING flag active (set by FLUSH_START).
However, it is currently assumed that a FLUSH_STOP not preceded by a
FLUSH_START is correct behavior, and this will occur while autoplugging
pipelines are constructed. This leaves us with an unhandled edge case!
This patch explicitly disables sending sticky events when pushing a
FLUSH_STOP, instead of relying on the flushing flag of the pad, which
will break in the edge case of a FLUSH_STOP not preceded by a
FLUSH_START.
If sticky events are propagated in response to a FLUSH_STOP, the
flushing thread can end up deadlocked in blocking code of a downstream
pad, such as a blocking probe. Instead, those events should be
propagated from the streaming thread of the pad when handling a
non-flushing synchronized event or buffer.
This fixes a deadlock found in WebKit with playbin3 when seeks occur
before preroll, where the seeking thread ended up stuck in the blocking
probe of playsink:
https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1367
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7632>
I wanted to check if an element had the SINK flag and realized it was
not displayed in gst-inspect.
The clock flags were already reported as part of the "clocking
capabilities" info but best to have them explicitly listed here as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7641>
