Age | Commit message (Collapse) | Author | Files | Lines |
|
Broken links mostly.
|
|
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
|
|
|
|
This is consistent with how it works for GstEvent already.
|
|
And also add the "Since" API sections for 1.12 and 1.14
|
|
And link to it
|
|
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
|
|
And make it explicit, and don't call _extract() on NULL data buffer.
|
|
We use this syntax in libs/gst/helpers/meson.build already.
|
|
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
|
|
|
|
Not only if a match pattern was set originally via GST_DEBUG.
Patterns might be set programmatically as well after all.
|
|
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.
|
|
g_strndup() wants a number of bytes to copy, so use strlen intead of
UTF-8 strlen function.
|
|
This reverts commit 81e10f61231ad56ca4aa07278993b87c6ec0f058.
A mistake lead to committing it twice in a weird way.
|
|
It will g_warn upon deserialization and we should not use
those anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=789871
|
|
With serialized GstDiscovererInfos we might end up trying to use
tags that have not been registered.
|
|
It will g_warn upon desarialization and we should not use
those anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=789871
|
|
|
|
Because
|
|
The array provided by backtrace_symbols needs to be freed.
|
|
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.
|
|
Useful for debugging.
|
|
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.
|
|
The state is as it should be, so no reason to return
FALSE really, everything's good.
|
|
|
|
An upstream query will take a ref on the internal proxypad, and can
hence end up owning the last reference to that pad, causing a crash.
|
|
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.
|
|
See https://bugzilla.gnome.org/show_bug.cgi?id=731301
https://bugzilla.gnome.org/show_bug.cgi?id=789986
|
|
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
|
|
This is in the same vein as for all other features. Some systems
might not allow unaligned read.
|
|
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
|
|
It's mostly a debug check and crash avoidance, it's better to
keep all the condition inside the macro.
|
|
|
|
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
|
|
To make it explicit that we are dealing with uint32 targets
Avoids erroneous runtime error: left shift of negative value -1
https://bugzilla.gnome.org/show_bug.cgi?id=789700
|
|
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.
|
|
|
|
|
|
This reverts commit f1baaae17557fa75a9bcd940b994597714be2f74.
|
|
If start and stop are set, calculate the duration and set it too.
|
|
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.
|
|
When updating the linked list, prev->next = next is correct
if prev is actually updated after being set to the head
of the list at the start.
https://bugzilla.gnome.org/show_bug.cgi?id=788617
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=788520
|
|
The GST_EXPORT should handle 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
|
|
Printing NULL is confusing when the type is e.g. a GArray that is not empty.
|