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
