IDLE probes that are directly called when being added will increase /
decrease the "number of IDLE probes running" counter around the call,
but when running from the streaming thread this won't happen.
This has the effect that when running from a streaming thread it is
possible to push serialized events or data out of the pad without
problems, but otherwise it would deadlock because serialized data would
wait for the IDLE probe to finish first (it is blocking after all!).
With this change it will now always consistently deadlock instead of
just every once in a while, which should make it obvious why this
happens and prevent racy deadlocks in application code.
https://bugzilla.gnome.org/show_bug.cgi?id=796895
And make use of it in the typefind element. It's useful to distinguish
between the different errors why typefinding can fail, and especially to
not consider GST_FLOW_FLUSHING as an actual error.
https://bugzilla.gnome.org/show_bug.cgi?id=796894
A regression was causing the helpers to be installed in /share which
would lead to permission denied error or PolicyKit to promtp for
permission. See:
054fa3aa2 meson: Use new define_variable: feature instead of run_command()
And make use of that in the typefind element to also be able to make use
of the extension in push mode. It previously only did that in pull mode
and this potentially speeds up typefinding and might also prevent false
positives.
https://bugzilla.gnome.org/show_bug.cgi?id=796865
This reverts commit 11e0f451eb.
When pushing a sticky event out of a pad with a pad probe or pad offset,
those should not be applied to the event that is actually stored in the
event but only in the event sent downstream. The pad probe and pad
offsets are conceptually *after* the pad, added by external code and
should not affect any internal state of pads/elements.
Also storing the modified event has the side-effect that a re-sent event
would arrive with any previous modifications done by the same pad probe
again inside that pad probe, and it would have to check if its
modifications are already applied or not.
For sink pads and generally for events arriving in a pad, some further
changes are still needed and those are tracked in
https://bugzilla.gnome.org/show_bug.cgi?id=765049
In addition, the commit also had a refcounting problem with events,
causing already destroyed events to be stored inside pads.
gst_base_transform_transform_caps can return NULL in various conditions
thus we should not treat its result as valid caps.
In all other places NULL is properly handled.
Previously gst_buffer_list_foreach() could modify (drop or replace)
buffers in non-writable lists, which could cause all kinds of problems
if other code also has a reference to the list and assumes that it stays
the same.
https://bugzilla.gnome.org/show_bug.cgi?id=796692
Every container of miniobjects now needs to store itself as parent in
the child object, and remove itself again at a later time.
A miniobject is only writable if there is at most one parent, and that
parent is writable itself, and if the reference count of the miniobject
is 1.
GstBuffer (for memories), GstBufferList (for buffers) and GstSample (for
caps, buffer, bufferlist) was updated accordingly.
Without this it was possible to have e.g. a bufferlist with refcount 2
in two places, modifying the same buffer with refcount 1 at the same
time.
https://bugzilla.gnome.org/show_bug.cgi?id=796692
The processing deadline is the acceptable amount of time to process the media
in a live pipeline before it reaches the sink. This is on top of the algorithmic
latency that is normally reported by the latency query. This should make
pipelines such as "v4lsrc ! xvimagesink" not claim that all frames are late
in the QoS events. Ideally, this should replace max_lateness for most applications.
https://bugzilla.gnome.org/show_bug.cgi?id=640610
The SNAP flags only make sense in combination with the KEY_UNIT flag,
and without they expose all kinds of unexpected behaviour in various
elements that don't expect this from happening.
Also warn if this ever happens.
https://bugzilla.gnome.org/show_bug.cgi?id=796558
Windows doesn't seem to have an equivalent of POLLPRI so disabled those
functions on this platform.
This API can be used, for example, to wait for video4linux events which
are using POLLPRI.
https://bugzilla.gnome.org/show_bug.cgi?id=794977
Current code was considering "can read" as having either POLLIN or POLLPRI being
set.
This may lead to client being awaken because of POLLPRI, starting a blocking
read and getting stuck because there is actually nothing to read.
This patch removes POLLPRI handling in read code and I'll add specific
API to wait for POLLPRI.
https://bugzilla.gnome.org/show_bug.cgi?id=794977
We need all relevant events of a segment to have consistent seqnum:
* GST_EVENT_SEGMENT
* GST_EVENT_EOS
If we are push-based and create a new segment, use the same seqnum
as the upstream event.
If we are pull-based, use the seqnum of that newly created segment
event everywhere
There is a possibility that the accumlation functions don't set
a seqnum. Make sure we only set/override the seqnum of the new
messages if we *have* a valid upstream seqnum to use
When using queue2 as a queue it was using GQueue with
individually allocated queue items, so two allocs for
each item. With GstQueueArray we can avoid those.
https://bugzilla.gnome.org/show_bug.cgi?id=796483
