The test checks that categories not covered by the pattern in the
GST_DEBUG string have debug level GST_LEVEL_DEFAULT set, but previous
tests mess with the default threshold, which made this test fail on
Windows or when run with CK_FORK=no. Fix this by resetting everything
at the beginning, and then also do a sanity check afterwards.
Start task on new source pads added at runtime after they
have been added to the element, not during activation.
This ensures the pads can post their CREATE stream-status
messages and the application can set thread priorities.
https://bugzilla.gnome.org/show_bug.cgi?id=756867
Sub-class may want to decide to go passthrough/in-place by inspecting
the support meta APIs. This patch duplicates the check for this mode,
so we still don't do uneeded allocation query while we allow sub-classes
to switch the behaviour during it's own decide_allocation call.
Notice that such sub-class need to reset the class to non-passthrough in
set_caps() in order for decide_allocation to be called again. This is
needed otherwise we'd be doing an allocation query in element in which
it make no sense (notably capsfilter).
https://bugzilla.gnome.org/show_bug.cgi?id=791453
Add a gst_base_src_submit_buffer_list() function that allows subclasses
to produce a bufferlist containing multiple buffers in the ::create()
function. The buffers in the buffer list will then also be pushed out
in one go as a GstBufferList. This can reduce push overhead
significantly for sources with packetised inputs (such as udpsrc)
in high-throughput scenarios.
The _submit_buffer_list() approach was chosen because it is fairly
straight-forward, backwards-compatible, bindings-friendly (as opposed
to e.g. making the create function return a mini object instead),
and it allows the subclass maximum control: the subclass can decide
dynamically at runtime whether to return a list or a single buffer
(which would be messier if we added a create_list virtual method).
https://bugzilla.gnome.org/show_bug.cgi?id=750241
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
Convenience function to just grab all pending data
from the harness, e.g. if we just want to check if
it matches what we expect and we don't care about
the chunking or buffer metadata.
Based on patch by: Havard Graff <havard.graff@gmail.com>
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
