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
