First load all system presets, then all from the environment variable, then
from the app directory, then from the user directory. Any one in the chain
with the highest version completely replaces all previous ones, later ones
with lower versions are merged in without replacing existing presets.
This is basically the same behaviour as before, just that GST_PRESET_PATH is
inserted as another source of directories between the system and app presets.
It was added in ca08af1f17, but was
accidentially overriding the user preset path there. Which caused inconsistent
behaviour as new presets were still stored in the system path, just not loaded
from there. Meaning you could store a new preset (in the user path), just for
GstPreset to not find it anymore later (because it only looked in the
GST_PRESET_PATH instead of the user path).
https://bugzilla.gnome.org/show_bug.cgi?id=764034
The alias define GST_TYPE_PARENT_BUFFER_META_API_TYPE is wrong and
breaks the usage of gst_buffer_get_parent_buffer_meta().
This patch fixes the GType alias and make another alias to keep the API
compatibility guarded by GST_DISABLE_DEPRECATED.
Also added a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=763112
gst_structure_new_empty() is not returning NULL in any valid scenarios,
checking for NULL here is useless. Especially because we would dereference any
NULL right after the NULL check again.
CID 1352037.
We previously check if the string ends on .class, as such strrchr() should
return something non-NULL. Add an assertion for that.
CID 1349642.
Pretty much every single element does
gst_element_class_add_pad_template (element_class,
gst_static_pad_template_get (&some_templ));
which is both confusing and unnecessary. We might just
as well add a function to do that in one step.
https://bugzilla.gnome.org/show_bug.cgi?id=762778
When holding a regular ref it will cause the GstBus to never
reach 0 references and it won't be destroyed unless the application
explicitly calls gst_bus_remove_signal_watch().
Switching to weakref will allow the GstBus to be destroyed.
The application is still responsible for destroying the
GSource.
https://bugzilla.gnome.org/show_bug.cgi?id=762552
This reverts commit b427997119.
It breaks things that used to work before, even if the change by itself is
correct and the previous code is just working around deeper bugs in the async
state change code. Let's go back to what previously worked and then fix async
state changes in general.
https://bugzilla.gnome.org/show_bug.cgi?id=760532
When calling gst_pad_activate_mode() on a ghostpad
gst_ghost_pad_activate_push_default() will be called. This will call
gst_pad_activate_mode() on the proxypad (which is internal of the
ghostpad), calling gst_ghost_pad_internal_activate_push_default(), which
again will call gst_pad_activate_mode() on the original ghostpad.
By simply returning TRUE in
gst_ghost_pad_internal_activate_push_default() the redundant call to
gst_pad_activate_mode() (for the same pad) is avoided.
https://bugzilla.gnome.org/show_bug.cgi?id=761913
When allocating a new buffer in the pool, both the do_alloc_buffer() and the
vmethod, alloc_buffer(), receive the parameter GstBufferPoolAcquireParams.
Nonetheless, when default_acquire_buffer() calls the do_alloc_buffer() it does
not pass the received GstBufferPoolAcquireParams, so when the user pass those
parameters they are ignored by alloc_buffer() vmethod.
This one-liner patch pass the received acquire params to do_alloc_buffer().
https://bugzilla.gnome.org/show_bug.cgi?id=761824
Fixes a race where an entry is set to BUSY in
gst_system_clock_id_wait_jitter() and is UNSCHEDULED before
gst_system_clock_id_wait_jitter_unlocked() starts processing it. The
wakeup added by gst_system_clock_id_unschedule() must be cleaned up.
Two stress tests are added. One test that triggers the specific issue
described above. The second stresses the code path where a wait is
rescheduled because the poll returned early.
https://bugzilla.gnome.org/show_bug.cgi?id=761586
If the clockentry is too late and is unscheduled before it gets
a change to detect its lateness the wakeup count and the poll are
used but never properly cleaned up. This leaves it in a dirty state
that is going to mess with the next clock entry waiting requests.
https://bugzilla.gnome.org/show_bug.cgi?id=761586
Change the gst_tracer_record_new() api to take the parameters the make the
spec structure directly. This allows us to own the top-level structure and
also collect the args so that we can take ownership of the sub-structures.
https://bugzilla.gnome.org/show_bug.cgi?id=760821
We're comparing a pointer type with '\0' here, which
probably isn't right, and the loop condition made sure
that classes[0] is != NULL already, so it's pointless.
Was probaby meant to check if the string pointed to is
not empty, so make it do that instead.
When choosing the first entry from the list, gst_system_clock_async_thread
must set the entry state to busy before releasing the clock lock. Otherwise
a new entry could be added to the beginning of the list and
gst_system_clock_async_thread will be unaware and keep waiting on the entry
it has already chosen.
Also improved messages about expected state and bumped them to ERROR level
to detect unexpected state changes.
https://bugzilla.gnome.org/show_bug.cgi?id=760757
self->spec is got using g_value_get_boxed(), which is a transfer none function.
So the same should not be freed, which is resulting in wrong behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=760821
GstTracerValueFlags is not being initialized and the same could result in wrong
comparision and behavior. Hence initializing it to GST_TRACER_VALUE_FLAGS_NONE.
https://bugzilla.gnome.org/show_bug.cgi?id=760821
Only hide GstTracer and GstTracerRecord API behind GST_USE_UNSTABLE_API,
but don't spew any warnings, otherwise everyone has to define this
to avoid compiler warnings.
This reverts parts of commit 89ee5d948d.
We use this class to register tracer log entry metadata and build a log
template. With the log template we can serialize log data very efficiently.
This also simplifies the logging code, since that is now a simple varargs
function that is not exposing the implementation details.
Add docs for the new class and basic tests.
Remove the previous log handler.
Fixes#760267
If no providers for a particular class could be found, then removing unmatched
filters would cause all devices to be returned instead which is not at all what
the user intended. We still return 0 for unmatched filters.
Other gst libraries and/or elements may want to add some debug logging to an
external debug system or implement delayed debugging for performance reasons.
Exposes the internal __gst_vasprintf as gst_info_vasprintf which has a fallback
to g_vasprintf if the debug system is disabled.
API: gst_info_vasprintf
API: gst_info_strdup_vprintf
API: gst_info_strdup_printf
https://bugzilla.gnome.org/show_bug.cgi?id=760421
GstControlSourceGetValue() value paramater is a gdouble, not a GValue
and GstControlSourceGetValueArray doesn't return a GstValueArray but
an array of double.
https://bugzilla.gnome.org/show_bug.cgi?id=758668
Previously we used the latter one still for the tracer utility code, causing
undefined references in the resulting binary if the debugging system was
disabled but the tracer system not.
It's used by the debugging and tracer subsystem and in various files, make it
a central thing that is initialized independ of the existence of those
subsystems.
The parse-launch API automagically handles dynamic pads and performs delayed
linking as needed, without any feedback about whether the linking succeeded or
not however. If a delayed dynamic link can't be completed for whatever reason,
parse-launch will simply wait in case a suitable pad appears later. This may
never happen though, in which case the pipeline may just hang forever.
Try to improve this by connecting to the "no-more-pads" signal of any element
with dynamic pads and posting a warning message for the related outstanding
dynamic links when "no-more-pads" is emitted.
Fixes#760003
'gst_element_post_message' takes the ownership of the message, so it
shall unref it when there is no post_message implementation. Otherwise
message is leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=759300
This lock seems to exist only to prevent elements from changing states while
events are being processed. However events are going to be processed
nonetheless in those elements if sent directly via pads, so protection must
already be implemented inside the elements for event handling if it is needed.
As such having the lock here is not very useful and is actually causing
various deadlocks in different situations as described in
https://bugzilla.gnome.org/show_bug.cgi?id=744040
Otherwise each bin might have a different latency in the end, causing
synchronization problems.
The bin will still first handle latency internally as before, but gives the
overall pipeline the opportunity to update the latency of the whole pipeline
afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=759125
The pad could be activated but flushing because of a FLUSH_START event. That's
not what we're looking for here, we want to check for activated pads.
https://bugzilla.gnome.org/show_bug.cgi?id=758928
This is useful for feature that are produced after probing a specific
node. You want to reload this plugin if the specific node(s) have been
removed, added, or reloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=758080
In plugin is responsible for calculating a hash of the dependencies
in order to determine if the cache should be invalidated or not.
Currently, the hash combining method removes a bit of the original
have before combining with an addition. As we use 32bits for our hash
and shift 1 bit for each file and directory, that resulting hash only
account for the last 32 files. And is more affected by the last file.
Rotating technique (shifting, and adding back the ending bit), can be
use to make the addition non-commutative. In a way that different order
gives different hashes. In this case, I don't preserve this behaviour
because the order in which the files are provided by the OS is
irrelevant.
In most cases, the XOR operation is used to combine hashes. In this
code we use the addition. I decided to preserve the addition because
we make use of non-random hash ((guint) -1) in the algorithm for
matching files that are not really part of the hash (symlinks, special
files). Doing successive XOR on this value, will simply switch from
full ones, to full zero. The XOR used with whitelist has been preserved
as it's based on a fairly randomized hash (g_str_hash).
https://bugzilla.gnome.org/show_bug.cgi?id=758078
