Without this it is possible that we have a GSource with reference count
0 stored in the GstBus that is currently in the process of being
destroyed. gst_bus_remove_watch() might then access it, increase its
reference count to 1 again, call GSource API on it and then unref it,
which will then finalize it a second time.
The dispose function allows the GSource to be resurrected until it
returned so the above would be safe now.
This caused some spurious crashes during shutdown in various
applications.
It fixes below gir warnings.
../subprojects/gstreamer/gst/gstevent.c:2246: Warning: Gst:
gst_event_new_instant_rate_sync_time: unknown parameter
'rate_multiplier' in documentation comment, should be 'rate'
../subprojects/gstreamer/gst/gstevent.c:2296: Warning: Gst:
gst_event_parse_instant_rate_sync_time: unknown parameter
'rate_multiplier' in documentation comment, should be 'rate'
After release bison 2.5 the declaration %pure-parser was deprecated
in favor of %define api.pure
Nonetheless, until bison 3.4, the declaration was treated as backward
compatibility, but now bison shows a warning:
warning: deprecated directive, use ‘%define api.pure’
The patch's approach is to handle both directives according with the
used bison's version, by string replacement at source configuration
stage.
When playing gapless there were situations when some sticky events
like tags were stuck at some pad and then revived much later.
Therefore it is better to clear them upon stream-start.
Fixes#360
A seek with that flag set must be non-flushing, not change the playback
direction and start/stop position. A seek handler will then send the new
GST_EVENT_INSTANT_RATE_CHANGE event downstream for downstream elements
to immediately apply the new playback rate before the new in-band segment
event arrives.
The argument must be at least a GObject according to the GstLogFunction
definition, and while the default C log function handles miniobjects
just fine this is crashing bindings and user-supplied log functions that
(rightfully) don't expect anything but GObjects.
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
