gst_element_post_message() takes ownership of the message so we need to increase
its refcount until we no longer require access to its data (context_type).
https://bugzilla.gnome.org/show_bug.cgi?id=797099
And only ever use the non-live values if all pads are non-live,
otherwise only use the results of all live pads.
It's unclear what one would use the values for in the non-live case, but
by this we at least pass them through correctly then.
This is a follow-up for 794944f779, which
causes wrong latency calculations if the first pad is non-live but a
later pad is actually live. In that case the live values would be
accumulated together with the values of the non-live first pad,
generally causing wrong min/max latencies to be calculated.
Fixes for gst_segment_position_from_running_time_full() when
converting running_times that precede the segment start (or
stop in a negative rate segment)
The return value was incorrectly negated in those cases.
Add some more unit test checks for those cases, and especially
for segments with offsets.
Instead, use -fvisibility=hidden and explicit exports via GST_EXPORT.
This should result in consistent behaviour for the autotools and
Meson builds where this is done already, and will allow us to drop
the win32 .def files.
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
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.
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 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
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
Probes were remembering a cookie that was used to check if the probe was
already called this time before the probes list changed. However the
same probes could've been called by another thread in between and thus
gotten a new cookie, and would then be called a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=795987
strncpy() is assumed to be for strings so the compiler assumes that
it will need an extra byte for the string-terminaning NULL.
For cases where we know it's actually "binary" data, just copy it
with memcpy.
https://bugzilla.gnome.org/show_bug.cgi?id=795756
gst_buffer_list_new_sized(0) will cause an underflow in a calculation
which then makes it try to allocate huge amounts of memory, which
may lead to aborts.
https://bugzilla.gnome.org/show_bug.cgi?id=795758
Update documentation on non existent option `gst-enable-gst-debug'. Instead,
one has to make sure that the `--disable-gst-debug' option was not used when
compiling GStreamer (i.e., `./configure --disable-gst-debug').
https://bugzilla.gnome.org/show_bug.cgi?id=795801
Meson supports building both static and shared libraries in a single
library() call. It has the advantage of reusing the same .o objects and
thus avoid double compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=794627
In the case where the user sets a new padprobeinfo->data in a probe
where the data is a sticky event, the new sticky event should be automatically
sticked on the probed pad.
https://bugzilla.gnome.org/show_bug.cgi?id=795330
