Not posting DEVICE_ADDED messages while a device provider is being
started makes things awkward for applications, as they have to call
get_devices() after starting the monitor.
This requires redundant code on the application side, and as far as
I understand also could cause race conditions, when a device gets
added between the calls to gst_device_monitor_start() and
gst_device_monitor_get_devices(), causing the application to "see"
the same device twice.
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
gst_pad_iterate_internal_links is usually used to find a single internal
link that a pad has, e.g. to find the corresponding pad of a multiqueue.
Added a helper function that will return either a single internal link,
if there's no other, or NULL.
In cases with many long-lived buffers that have qdata only very
briefly, the memory overhead of keeping an array of 16 GstQData
structs for each buffer can be significant. We free the array when
the last qdata is removed, like it was done in 1.14.
Fixes#436
This patch simply add a null check around a case where a child may have
been unparented concurrently to the deep_add_remove operation. This was
found by accident in the form of an "IS_GST_OBJECT" assertion, but had
no other known side effect in that test.
`g_object_notify()` actually takes a global lock to look up the
`GParamSpec` that corresponds to the given property name. It's not a
huge performance hit, but it's easily avoidable by using the
`_by_pspec()` variant.
On Windows, concurrent colored gstreamr debug output and usual
stdout/stderr string will cause broken output on terminal.
Since it's OS specific behavior, that's hard to completely avoid it
but we can protect it at least among our printing interfaces side.
For buffers with multiple memory chunks, gst_buffer_map() has the side
effect of merging the memory chunks into one contiguous
chunk. Since gst_util_dump_mem() used gst_buffer_map() the internals
of the buffer could actually change as a result of printing it.
For the case of a buffer containing several memory chunks,
gst_memory_map() is now used to obtain the memory address and each
memory chunk is dumped separately preceded by a header line. The
behaviour for a buffer containing a single memory chunk is left unchanged.
This was added in 1.16 and accidentally duplicated the value of
the existing GST_MESSAGE_REDIRECT.
As the only known user of this message is GStreamer core itself,
and it is quite an obscure message, it seems best to just fix up
the enum value even if that technically breaks API.
Fixes#418
gst_ring_buffer_logger_log calls several functions while formatting
the message which may in turn log a message while we already hold
the mutex. Do all formatting first before acquiring the mutex to
avoid this and reduce the time we hold the mutex.
And change it to do nothing at all.
As debug categories don't use reference counting and they can be
retrieved from anywhere at any time by name, it is fundamentally unsafe
to free them at any point in time except for right before the end of the
process.
No code apart from a unit test seems to be currently using the function,
so deprecate it and also change it to do nothing at all.
This will be useful in the next commit where we add action-signals on
the leaks tracer to get information about leaks and to manipulate
checkpoints as a replacement for the SIGUSR1 and SIGUSR2 signals for
doing the same.
The offset in gst_buffer_resize() is additive. So to move back the
offset to zero, we need to pass the opposite of the current offset. This
was raised through the related unit test failingon 32bit as on 64bit
the alignment padding was enough to hide the issue. The test was
modified to also fail on 64bit. This patch will remove spurious
assertions like:
assertion 'bufmax >= bufoffs + offset + size' failed
Fixes#316
It's not really possible for us to recover when someone uses the
gst_tracer_record_new() API incorrectly. Also, document a piece of
somewhat-obscure code.
Ensure that the code paths for HAVE_UNWIND and HAVE_DBGHELP are never
taken at the same time, even if the build file code changes.
Prefer DbgHelp over libunwind on Windows in case both are somehow
available because DbgHelp is only available when building with the
MSVC toolchain, and libunwind won't give us debug symbols from objects
built with the MSVC toolchain.
Also, print slightly more useful messages for the level of stack trace
support enabled, and document what each if conditional does.
The code implicitly uses this value when the stack trace is not FULL.
Mostly useful for documenting the behaviour when each flag is passed
and for translating to/from strings.
When using GStreamer with Universal Windows Platform apps, dynamic
plugins can only be loaded by filename (without a path) using
gst_plugin_load_file() which will call into g_module_open().
On Windows, GModule calls LoadLibrary() on the filename, but with
UWP we need to use LoadPackagedLibrary() which is basically the same
as LoadLibrary(), except it looks only for DLLs (by name) that have
been packaged as assets with the app.
These assets are not files and cannot be accessed using normal file
APIs such as open() or stat().
The upstream glib merge request for adding LoadPackagedLibrary support
is: https://gitlab.gnome.org/GNOME/glib/merge_requests/951
NOTE: Whitespcae removal is to make gst-indent happy
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means
we no longer need the macro there, but for most types in core we don't
want to break ABI, which means it's better to just keep it like it is
(and use the `#ifdef` instead).
Before GST_PAD_PROBE_HANDLED was introduced, we had to handle the case
where some probes would reset the probe info data field to NULL. This would
be considered an invalid use-case.
But with GST_PAD_PROBE_HANDLED it is totally fine to reset that, since
the probe has "handled" it.
* Making sure that `static inline` function are in the GIR (by first
defining them, and make sure to mark as skiped)
* Do not try to link to unexisting symbols
* Also generate GIR information about gst_tracers
Instead of the object value, this should be used every time a random
value will be returned by g_object_get This is also useful to make the
values returned by inspecting element stable accross runs.
And add strduped function pointer names to the global quark
table, so that they don't get reported as lost by valgrind.
This allows us to use GST_DEBUG when running tests under
valgrind.
Creating seek events segfaults on 32-bit ARM since commit 2fa15d5371
('event: add new seek parameter, "trickmode-interval"'), which missed
casting the trickmode-interval initializer in the variable argument list
to guint64.
Otherwise we'll get an assertion if the object behind the weak pointer
was already destroyed in the meantime as we would pass NULL as first
argument to g_object_remove_weak_pointer().
When performing a key unit trickmode seek, it may be useful to
specify a minimum interval between the output frames, either
in very high rate cases, or as a protection against streams
that may contain an overly large amount of key frames.
One use case is ONVIF Section 6.5.3:
<https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf>
There is a deadlock if any thread from the pool tries to push
a new task while other thread is waiting for the pool of threads
to finish. With this patch the thread will get an error when it
tries to add a new task while the taskpool is being cleaned up.
MSVC also defines it as a keyword. Fixes build errors in projects that
include MSVC's xkeycheck.h which ensures that keywords aren't overriden
with a define.
Between getting the GSource with the mutex and destroying it, something
else might've destroyed it already and we would have a dangling pointer.
Keep an additional reference just in case.
Signal watches are reference counted and gst_bus_remove_watch() would
immediately remove it, breaking the reference counting. Only
gst_bus_remove_signal_watch() should be used for removing signal
watches.
For metas where order might be significant if multiple metas are
attached to the same buffer, so store a sequence number with the
meta when adding it to the buffer. This allows users of the meta
to make sure metas are processed in the right order.
We need a 64-bit integer for the sequence number here in the API,
a 32-bit one might overflow too easily with high packet/buffer
rates. We could do it rtp-seqnum style of course, but that's a
bit of a pain.
We could also make it so that gst_buffer_add_meta() just keeps metas in
order or rely on the order we add the metas in, but that seems too
fragile overall, when buffers (incl. metas) get merged or split.
Also add a compare function for easier sorting.
We store the seqnum in the MetaItem struct here and not in the
GstMeta struct since there's no padding in the GstMeta struct.
We could add a private struct to GstMeta before the start of
GstMeta, but that's what MetaItem effectively is implementation-
wise. We can still change this later if we want, since it's all
private.
Fixes#262
Thi introduces new APIs to post a `DEVICE_CHANGED` message on the
bus so the application is notifies when a device is modified. For
example, if the "defaultness" of a device was changed or any property
that can be changed at any time. Atomically changing the device
object notifying that way allow us to abtract away the internal threads.
New APIS:
- gst_message_new_device_changed
- gst_message_parse_device_changed
- gst_device_provider_device_changed
The hook->hook_id is a gulong for which there are no portability issues
when tracing in printf format with %lu. So use %lu and remove the upcast
to 64 bit. This makes the code more consistent with everything else
tracing that hook_id and other gulong id.
This was added in 7fdb15d6a2 but it is wrong. (scope call) is for
closures that only have to stay valid for the scope of the call, but the
tag merge function has to stay valid for the whole lifetime of the
application instead.
There's no appropriate scope annotation for that so we have to skip
these functions for now.
GstDeviceProvider has a started_count private variable counter,
and the gst_device_provider_start() documentation emphasizes the
importance of balancing the start and stop calls.
However, when starting a provider that is already started, the
current code will never increment the counter more than once.
So you start it twice, but it will have start_count 1, which is the
maximum value it will ever see.
Then when you stop it twice, on the 2nd stop, after decrementing the
counter in gst_device_provider_stop():
else if (provider->priv->started_count < 1) {
g_critical
("Trying to stop a GstDeviceProvider %s which is already stopped",
GST_OBJECT_NAME (provider));
and the program is killed.
Fix this by incrementing the counter when starting a device provider that
was already started.
This is racy if the state lock of the parent bin is not taken. The
parent bin might've just checked the flag in another thread and as the
next step proceed to change the child element's state.
We need to take the state lock here to ensure that we're
not currently just before setting the state of this child
element. Otherwise it can happen that we removed the element
here and e.g. set it to NULL state, and shortly afterwards
have another thread set it to a higher state again as part of
a state change for the whole bin.
When adding an element to the bin this is not needed as we
require callers to always ensure after adding to the bin that
the new element is set to the correct state.
There was a dead assignment used outside of the bin/pipeline creation
which was confusing (and unused). Just move that variable to
where it is actually used.
(Note that that variable was not needed outside of that block since
the refactoring done in 2b33d33185 )
Fix corruption of meta list head when removing metas at the beginning
during iteration. Linked list handling in gst_buffer_foreach_meta
failed to track the previous entry and update the correct next pointer
when removing items from beyond the head of the list, resulting in
arbitrary list pointer corruption.
Closes#332
Currently in Python it would become a signed 64 bit value but should
actually be an unsigned 32 bit value with all bits set.
This is the same problem as with GST_MESSAGE_TYPE_ANY.
See https://bugzilla.gnome.org/show_bug.cgi?id=732633
We won't be able to do ASSERT_CRITICAL, but the main body of the tests
are still valid, and given we ship GStreamer with this configuration, it
is important to be able to run some tests against it.
Allows determining from downstream what the expected bitrate of a stream
may be which is useful in queue2 for setting time based limits when
upstream does not provide timing information.
Implement bitrate query handling in queue2
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/60
A pointer to a hook in this list can easily not be unique, given both
the slice-allocator reusing memory, and the OS re-using freed blocks
in malloc.
By doing many repeated add and remove of probes, this becomes very easily
reproduced.
Instead use hook_id, which *is* unique for a added GHook.
This is based on g_clear_object(). Basically, you can use this instead
of using gst_mini_object_unref (which needs to be preceded by a NULL-check).
Also fixes#275
If a segment has stop == -1, then gst_segment_to_running_time()
would refuse to calculate a running time for negative rates,
but gst_segment_do_seek() allows this scenario and uses a
valid duration for calculations.
Make the 2 functions consistent by using any configured duration
to calculate a running time too in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=796559
GST_TIME_FORMAT, GST_TIME_ARGS, GST_STIME_FORMAT, GST_STIME_ARGS
GST_PTR_FORMAT, GST_SEGMENT_FORMAT, GST_FOURCC_FORMAT and
GST_FOURCC_ARGS are format specifiers.
They can't be used outside of C and should be generated in the gir.
https://bugzilla.gnome.org/show_bug.cgi?id=797320
The Harware factory type classifier allows elements (decoders and encoders,
mostly) to advertize they rely on hardware devices to perform encoding or
decoding operations. This classifier can be used by applications to filter and
select only the elements that use hardware devices, for instance to ensure
zero-copy support is enabled for a specific pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=796921
In some cases the system protection ID is not present in the contents
or in their metadata.
This define is used to set the value of the "system_id" field in GstProtectionEvent,
with this value, the application will use an external information to choose which
protection system to use.
Example: The matroskademux uses this value in the case of encrypted WebM,
the application will choose the appropriate protection system based on the information
received through EME API.
https://bugzilla.gnome.org/show_bug.cgi?id=797231
The documentation incorrectly used to state that the pads were
not automatically activated when added, whereas we actually do
that when appropriate.
Callers of gst_element_add_pad must not hold the object lock,
which implies that they cannot perform the same checks as
add_pad in a non-racy manner.
This updates the documentation, and removes the g_warning
that was output before performing automatic activation.
https://bugzilla.gnome.org/show_bug.cgi?id=797181
Add new GST_API_EXPORT in config.h and use that for GST_*_API
decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
This is for use by the various GST_*_API decorators and
will be what they get defined to when a library API is being
used by external users of that library (not the library itself
whilst it's being compiled).
In most cases it will simply map to a plain 'extern' but on
Windows with MSVC it will need to map to __declspec(dllimport).
For functions this is not strictly needed, but for exported
variables it is.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
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
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
