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
RISC-V supports unaligned accesses, but these might run extremely slowly
depending on the implementation. Therefore set GST_HAVE_UNALIGNED_ACCESS
to 0 on this architecture.
https://bugzilla.gnome.org/show_bug.cgi?id=795271
gst_sample_set_buffer
gst_sample_set_caps
gst_sample_set_segment
gst_sample_set_info
gst_sample_is_writable
gst_sample_make_writable
This commit makes it possible to reuse a sample object and avoid
unnecessary memory allocations, for example in appsink.
In addition, writability is now required to set the buffer list.
https://bugzilla.gnome.org/show_bug.cgi?id=795144
When outputting debug logs on Windows, some sections are protected
with a non-recursive lock. Turns out though that gst_debug_message_get()
might indirectly, via our printf format extensions, call code which
in turn would try to log something when it can't handle something. If
that happens we end up in gst_debug_log_default() again recursively and
try to again take the lock that's already taken, thus deadlocking.
Format the debug message string outside of the critical section
instead to avoid this.
https://bugzilla.gnome.org/show_bug.cgi?id=784382
Remove unneeded reapplication of patterns. Besides being
superfluous (gst_debug_reset_threshold already applies
patterns) it was also wrong and didn't stop checking patterns
after the first match (broken in 67e9d139).
Also fix up unit test which checked for the wrong order.
https://bugzilla.gnome.org/show_bug.cgi?id=794717
Replace the while+goto with a for+break and check walk to determine
whether we had a match. Move up the unlock to keep the locked section as
small as possible.
https://bugzilla.gnome.org/show_bug.cgi?id=794717
Move the match, logging and set_threshold to a new function.
The log levels are different, so choose the higher one (LOG). Having two
equivalent messages at two different levels seems like a bad idea
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=794717
Enhance default_reset_buffer() to resize the buffer to its full size if the
memory hasn't changed. This allows to reuse the buffer even if the offset has
changed or the size has shrunk, rather than freeing the buffer.
Change related to: https://bugzilla.gnome.org/show_bug.cgi?id=772841
g_object_ref() forwards the type of its argument nowadays.
./grammar.y:409:14: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
gstchildproxy.c:212:7: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
This can be used to identify buffers for which a higher percentage
of redundancy should be allocated when performing forward error
correction, or to prevent still video frames from being dropped by
elements due to QoS.
https://bugzilla.gnome.org/show_bug.cgi?id=793008
The following case can happen when two thread try to activate and
deactivate a pad at the same time:
T1: starts to deactivate, calls pre_activate(), sets in_activation
to TRUE and carries on
T2: starts to activate, calls pre_activate(), in_activation is TRUE
so it waits on the GCond
T1: calls post_activate(), tries to acquire the streaming lock ..
but can't because T2 is currently holding it
With this patch, the deadlock will no longer happen but does not
solve the problem that:
T2: will resume activation of the pad, set the pad mode to the target
one (PUSH or PULL) and eventually the streaming lock gets released.
T1: is able to finish calling post_activate() ... but ... the pad
wasn't deactivated (T2 was the last one to "activate" the pad.
https://bugzilla.gnome.org/show_bug.cgi?id=792341
This is a better fit given that the function docs say this
should (only) be used for interval measurements, but also
this seems to give much better granularity on Windows
systems, where before this change there would often be
10-20 lines of debug log with the same timestamp up front.
Fix refcounting issue when plugin was loaded already.
gst_plugin_load() is supposed to return a ref, so it
must always return a ref.
This also fixes the gstplugin unit test on windows where
fork is not available and where test_load_coreelements()
would unref a plugin ref it didn't get and then mess up
the internal registry plugin list state for the next test,
in case where the test registry does not exist yet.
When actually pushing an event, if we get GST_FLOW_CUSTOM_SUCCESS_1
(which is the conversion of GST_PAD_PROBE_HANDLED return value),
don't consider the stick event push as ignored, but as handled
Various plugins use special values (0 or G_MAXUINT32) as an
invalid/unset group_id, but nothing guarantees a groupid won't have
that value.
Instead define a value which group_id will never have and make
gst_group_id_next() always return a value different from that.
API: GST_GROUP_ID_INVALID
While the refcount of the pad is decreased, it's the refcount that is
owned by the parent (i.e. the element) and not the one passed in by the
caller.
Fixes a memory leak in bindings.
On Arch Linux x86_64, gcc 7.2.0-3, -Og -g3:
gstdevicemonitor.c: In function ‘bus_sync_message’:
gstdevicemonitor.c:276:8: error: ‘matches’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
This commit also simplifies the code a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=789983
When registering a new debug category after gst_init(), simply check
the existing patterns against that new category.
No need to iterate over all categories and recheck them all against
the existing patterns.
Also, no need to re-parse the existing pattern string set via GST_DEBUG
and add the same set of match patterns all over again to the existing
list of match patterns every time we register a new debug category.
Combined with iterating all debug categories on a change this would
make adding debug categories after gst_init() very very very slow.
The check for dropping precision was wrong when sxx and syy were negative.
if they are negative then "G_MAXINT64 - val" would always overflow
The check was meant to use G_MININT64 (like in the loop contained just
after).
`./configure --disable-gst-tracer-hooks` didn't do anything, hooks were
always enabled regardless of the option. It works correctly in the
Meson build though.
Checking that the pad is in the correct mode before the parent is
checked makes the call always succeed if the mode is ok.
This fixes a race with ghostpad where gst_pad_activate_mode() could
trigger a g_critical() if the ghostpad is unparented while the
proxypad is deactivating, for instance if the ghostpad is released.
More specifically, gst_ghost_pad_internal_activate_push_default()'s
call to gst_pad_activate_mode() would fail if ghostpad doesn't have a
parent. With this patch it will return true of mode is already
correct.
If we pre-allocate only *exactly* as many nodes as we need for the
core types, we are practically guaranteed a re-alloc when external
code like GstVideoTimeCode or GstEncodingProfile register their
own GstValue things. So allocate a bit more than strictly needed.
An object that can be waited on and asked for asynchronous values.
In much the same way as promise/futures in js/java/etc
A callback can be installed for when the promise changes state.
Original idea by
Jan Schmidt <jan@centricular.com>
With contributions from
Nirbheek Chauhan <nirbheek@centricular.com>
Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=789843
The following could happen previously:
* T1: calls gst_pad_set_active()
* T2: currently (de)activating it
* T1: gst_pad_set_active() returns, caller assumes that the pad has
completed the requested (de)activation ... whereas it is not
the case since the actual (de)activation in T2 might still be
going on.
To ensure atomicity of pad (de)activation, we use a internal
variable (and cond) to ensure only one thread at a time goes through
the actual (de)activation block
https://bugzilla.gnome.org/show_bug.cgi?id=790431
checking whether we already were in the target GstPadMode was being
done too early and there was the risk that we *would* end up
(de)activating a pad more than once.
Instead, re-do the check for pad mode when entering the final pad
(de)activation block.
https://bugzilla.gnome.org/show_bug.cgi?id=790431
Add convenience API that iterates over all pads, sink pads or
source pads and makes sure that the foreach function is called
exactly once for each pad.
This is a KISS implementation. It doesn't use GstIterator and
doesn't try to do clever things like resync if pads are added
or removed while the function is executing. We can still do that
in future if we think it's needed, but in practice it will
likely make absolutely no difference whatsoever, since these
things will have to be handled properly elsewhere by the element
anyway if they're important.
After all, it's always possible that a pad is added or removed
just after the iterator finishes iterating, but before the
function returns.
This is also a replacement for gst_aggregator_iterate_sink_pads().
https://bugzilla.gnome.org/show_bug.cgi?id=785679
Asking to select no streams makes no sense and can create various
issues.
If one doesn't one any stream it should deactivate (or not use) the
element in question.
Various plugins use the value of '0' as an invalid seqnum value
(qtdemux for matching duplicated seek events, for example). Make
that behaviour explicit, create a GST_SEQNUM_INVALID value,
and ensure gst_util_seqnum_next never returns it.
For linked elements, the resulting gst_bin_iterate_sorted() will
properly return elements from sink to sources.
If we have some elements that are not linked, we *still* want to
ensure that we return:
* In priority any sinks
* Last of all any sources
* And in between any element which is neither source nor sink
For this to work, when looking for the next candidate element,
not only check the degree order, but if there are two candidates
with the same degree order, prefer the non-source one.
Amongst other things, this fixes the case where we activating a
bin containing unlinked sources and other elements. Without this
we could end up activating sources (which might start adding pads
to be linked) before other (to which those new source element pads
might be linked) are not activated
https://bugzilla.gnome.org/show_bug.cgi?id=788434
There were a few errors:
* The plugin scanner now accepts executable path as an argument.
In case it is NULL, argc == 2
* We find the executable path in init_pre instead of gst_init,
allowing this to work when gst is initialized through the
option group (eg gst-inspect)
* There was a semi-colon missing in the __APPLE__ #ifdef
When a plugin declares a dependency using this flag, all the
relative paths are considered to be relative to the path of
the main executable.
We try to determine the path of the executable portably,
with implementations provided for Linux, Windows and Mac.
If retrieval of the path fails, we will not detect changes.
In order for the main executable path to be the same when
scanning a plugin in a child process, a new variable is
exposed in gst_private.h, _gst_executable_path
https://bugzilla.gnome.org/show_bug.cgi?id=788152
If multiple probes are set on a pad and one probe returns either
GST_PAD_PROBE_HANDLED or GST_PAD_PROBE_DROPPED we need to stop
calling the remaining probes.
https://bugzilla.gnome.org/show_bug.cgi?id=787243
