This calls a function from another thread, asynchronously. This is to be
used for cases when a state change has to be performed from a streaming
thread, directly via gst_element_set_state() or indirectly e.g. via SEEK
events.
Calling those functions directly from the streaming thread will cause
deadlocks in many situations, as they might involve waiting for the
streaming thread to shut down from this very streaming thread.
This is mostly a convenience function around a GThreadPool and is for example
used by GstBin to continue asynchronous state changes.
https://bugzilla.gnome.org/show_bug.cgi?id=760532
Passing years > 9999, months > 12 or days > 31 to gst_date_time_new() will
cause an assertion and generally does not make much sense. Instead consider it
as a parsing error like hours > 24 and return NULL.
This previously caused uninitialized memory unless something else was
initializing all the fields explicitly to something.
To be on the safe side, we also allocate metas without init function to all
zeroes now as it was relatively common.
https://bugzilla.gnome.org/show_bug.cgi?id=764902
Be notified in the application thread via bus messages about
notify::* and deep-notify::* property changes, instead of
having to deal with it in a non-application thread.
API: gst_element_add_property_notify_watch()
API: gst_element_add_property_deep_notify_watch()
API: gst_element_remove_property_notify_watch()
API: gst_message_new_property_notify()
API: gst_message_parse_property_notify()
API: GST_MESSAGE_PROPERTY_NOTIFY
https://bugzilla.gnome.org/show_bug.cgi?id=763142
Checking the current element's state when we're adding pads to
the parent element is checking the wrong thing.
Silences a 'attempting to add an inactive pad to a running element'
warning when adding a ghost pad to a running parent bin of the parent
bin of the element.
https://bugzilla.gnome.org/show_bug.cgi?id=764176
This is a useful function to automatically add ghost pads when linking
two elements across bin boundaries without know their exact parentage.
e.g. when using gst_parse_bin_from_description (with or without it ghosting pads),
one can simply retreive the src/sink pads from the bin to link to another pad.
Similar functionality is provided by gst_element_link_pads{_full}() however only
by pad name rather than by actual pads.
API: gst_pad_link_maybe_ghosting_full
https://bugzilla.gnome.org/show_bug.cgi?id=764176
Updated the GST_REFCOUNTING logging so that it includes the pointer
address of the object that is being disposed or finalized.
With this change is is then possible to match up GST_REFCOUNTING log messages
for object allocation/disposal/finalization. This can help with diagnosing
"memory leaks" in applications that have not correctly disposed of all the
GStreamer objects it creates.
https://bugzilla.gnome.org/show_bug.cgi?id=749427
It returned TRUE when regression failed, while not setting any of the out
parameters. This caused uninitialized data from the stack to be used for
setting the clock calibration.
PUSH and PULL mode have opposite scenarios for IDLE and BLOCK
probes.
For PUSH it will BLOCK with some data type and IDLE won't have a type.
For PULL it will BLOCK before getting some data and will be IDLE when
some data is obtained.
The check in hook_marshall was specific for PUSH mode and would cause
PULL probes to fail to be called. Adding different checks for the mode
to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=761211
We want to use the flag/enum nicks here, not only because they
are shorter but also because in case of element-specific enums
and flags we abuse the enum/flag name field for the description,
and we don't want that printed in the dot file.
https://bugzilla.gnome.org/show_bug.cgi?id=763814
Make compiler issue a warning for common beginner mistakes such as:
...
gst_buffer_make_writable (buf);
gst_buffer_map (buf, &map, GST_MAP_WRITE);
...
and similar. Only do this for some functions for now.
Don't keep the registry locked whilst iterating over the plugins
or features with a filter function. This would deadlock if the
callback tried to access the registry from the function. Instead,
make a copy of the feature/plugin list and then filter it without
holding the registry lock. This is still considerably faster than
the alternative which would be to use a GstIterator.
https://bugzilla.gnome.org/show_bug.cgi?id=756738
By default, gst_parse_launch_full() creates a GstPipeline if there's more
than one toplevel element. Add a flag to let it use a GstBin instead.
Also fix the parser to let it use this flag for GST_TYPE_ELEMENT property
values, to avoid having GstPipelines inside other GstPipelines.
https://bugzilla.gnome.org/show_bug.cgi?id=763457
When going from READY to NULL all element pads are deactivated. If
simultaneously the pad is being removed from the element with
gst_element_remove_pad() and the pad is unparented, there is a race
where the deactivation will assert (g_critical) if the parent is lost at
the wrong time.
The proposed fix will check parent only once and retain it to avoid the
race.
https://bugzilla.gnome.org/show_bug.cgi?id=761912
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
On iOS/OSX g_get_current_time was used by default. However, mach_time is
the preferred high-resolution monotonic clock to be used on Apple
platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=758012
Helps catching when a state change is starting and ending.
It is also possible to track the end of state changes by checking the
async-done or state-change messages.
This is particularly important for elements that do async state changes.
Validate that the proxy pad indeed accepts the caps by also
comparing with the pad template caps, otherwise when the pad
had no internally linked pads it would always return true.
https://bugzilla.gnome.org/show_bug.cgi?id=754112
Instead of re-sending sticky events over and over to a not-linked
pad, mark them as sent the first time. If the not-linked came from
downstream, it already received the events. If the pad is actually
not-linked, the sticky events will be rescheduled when the
pad is linked anyway.
There is a similar explanation in gst_caps_make_writable, but the existing
documentation can be misleading since it does not define what 'is already
writable' means.
Also note when this function is meant to be used.
API: GST_BUFFER_DTS_OR_PTS
Many scenarios/elements require dealing with streams of buffers that
might have DTS set (i.e. encoded data, potentially reordered)
To simplify getting the increasing "timestamp" of those buffers, create
a macro that will return the DTS if valid, and if not the PTS
Updated gst_segment_position_from_stream_time and gst_segment_to_stream_time to reflect correct calculations for the case when the applied rate is negative.
Pasting from design docs:
===============================
Stream time is calculated using the buffer times and the preceding SEGMENT
event as follows:
stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time
For negative rates, B.timestamp will go backwards from S.stop to S.start,
making the stream time go backwards.
===============================
Therefore, the calculation for applied_rate < 0 should be:
stream_time = (S.stop - B.timestamp) * ABS (S.applied_rate) + S.time
and the reverse:
B.timestamp = S.stop - (stream_time - S.time) / ABS (S.applied_rate)
https://bugzilla.gnome.org/show_bug.cgi?id=756810
An ASYNC READY->PAUSED might have failed without the bin code noticing during
the state change, in which case we will never get PAUSED->READY and would leak
messages.
https://bugzilla.gnome.org/show_bug.cgi?id=756611
This way one can define new tracing probes without changing the core. We are
using our own quark table, as 1) we only want to initialize them if we're
tracing, 2) we want to share them with the tracers.
Instead of a single invoke() function and a 'mask', register to individual
hooks. This avoids one level of indirection and allows us to remove the
hook enums. The message enms are now renamed to hook enums.
This way we only expand the structure when we're logging. This allows us to
meassure the pure tracing seperately from the logging.
Also add some comments on further improvements.
Keep tracer base class in tracer and move core support into the utils module.
Add a unstable-api guard to the tracer.h so that external modules would need to
acknowledge the status by setting GST_USE_UNSTABLE_API.
When adding an element to a bin we need to propagate the GstContext's
to/from the element.
This moves the GstContext list from GstBin to GstElement and adds
convenience functions to get the currently set list of GstContext's.
This does not deal with the collection of GstContext's propagated
using GST_CONTEXT_QUERY. Element subclasses are advised to call
gst_element_set_context if they need to propagate GstContext's
received from the context query.
https://bugzilla.gnome.org/show_bug.cgi?id=705579
A proxy-pad should always proxy the caps related queries
and events to its down or upstream peers on the other side
of the element. Falling back to a caps query seems wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=754112
gst_segment_to_position might cause confusion, especially with the addition of
gst_segment_position_from_stream_time . Deprecated gst_segment_to_position
now, and replaced it with gst_segment_position_from_running_time.
Also added unit tests.
gst_segment_position_from_stream_time() will convert stream time into a
position in the segment so that gst_segment_to_stream_time() with that
position returns the same stream time. It will return -1 if the stream time
given is not inside the segment.
When a running-time-offset is stored in the event, it could become smaller
than 0 although the event is otherwise correct. This can happen when pad
offsets are used.
To prevent this, we set the timestamp to -diff, so that in the end the sum of
both is exactly 0.
https://bugzilla.gnome.org/show_bug.cgi?id=754356
This fixes a race where a state change may return failure if it has
request pads that are deactivated and removed (and thus have no
parent) at the same time as the element changes state and (de)activates
its pads.
https://bugzilla.gnome.org/show_bug.cgi?id=755342
In some cases, probes might want to handle the buffer/event/query
themselves and stop the data from travelling further downstream.
While this was somewhat possible with buffer/events and using
GST_PROBE_DROP, it was not applicable to queries, and would result
in the query failing.
With this new GST_PROBE_HANDLED value, the buffer/event/query will
be considered as successfully handled, will not be pushed further
and the appropriate return value (TRUE or GST_FLOW_OK) will be returned
This also allows probes to return a non-default GstFlowReturn when dealing
with buffer push. This can be done by setting the
GST_PAD_PROBE_INFO_FLOW_RETURN() field accordingly
https://bugzilla.gnome.org/show_bug.cgi?id=748643
It will make the default accept-caps handler use the pad template
caps instead of the query-caps result to check if the caps is
acceptable. This is aligned with what the design docs says the
accept-caps should do (be non-recursive) and should be faster. It
is *not* enabled by default, though.
API: GST_PAD_FLAG_ACCEPT_TEMPLATE
API: GST_PAD_IS_ACCEPT_TEMPLATE
API: GST_PAD_SET_ACCEPT_TEMPLATE
API: GST_PAD_UNSET_ACCEPT_TEMPLATE
https://bugzilla.gnome.org/show_bug.cgi?id=753623
If no date and only a time is given in gst_date_time_new_from_iso8601_string(),
assume that it is "today" and try to parse the time-only string. "Today" is
assumed to be in the timezone provided by the user (if any), otherwise Z -
just like the behavior of the existing code.
https://bugzilla.gnome.org/show_bug.cgi?id=753455
Add methods to add/remove the providers that should be hidden by this
provider. Also make a method to get a list of hidden providers.
This makes it possible to have multiple systems monitor the same devices
and remove duplicates.
Add a property to see all devices, even duplicate ones from hidden
providers.
The previous implementation was doing a direct call to the peer pad,
which resulted in query probes never being called on the original pad.
Instead of that, get the peer pad caps by using gst_pad_peer_query()
which will call probes in the expected fashion.
While calling gst_value_deserialize_sample, if there is a failure
after caps is ref'ed, then caps is getting leaked. Hence checking for
caps in fail: goto condition and unref'ing it
https://bugzilla.gnome.org/show_bug.cgi?id=753338
When running gst_registry_scan_plugin_file we were losing the
information about the registry being loaded and ended up adding the
plugin to the default registry which was not correct.
https://bugzilla.gnome.org/show_bug.cgi?id=752662
In case there is an IDLE probe fired from gst_pad_push_data and it
doesn't return GST_FLOW_OK, the code jumps to the probe_stopped
label which tries to unref the data object. However, at this point
the data object belongs downstream and must not be touched.
By setting data = NULL, the code skips this unref.
https://bugzilla.gnome.org//show_bug.cgi?id=753151
Release the monitor lock when calling the provider start/stop methods.
Because we release the lock now, We need to make sure we check the
cookie again and keep track of started and removed providers.
The deviceproviders are added to the array sorted by their rank. Make
sure we keep this ordering when removing a provider.
We use _prepend to collect the devices, use g_list_reverse to get the
devices in the right order; sorted by rank and in the same order as
returned by the provider.
The check for the presence of the parent in the presence of
the NEED_PARENT flag was missing for the chain function. Also keep
a ref on the parent in case the pad is removed mid-chain.
Don't copy memory metas if we only copied part of the buffer, didn't
copy memories or merged memories. In all these cases the memory
structure has changed and the memory meta becomes meaningless.
https://bugzilla.gnome.org/show_bug.cgi?id=751712
Do not ignore the caps argument when requesting a pad by template.
This is particularly harmful when the pad caps query by default
returns ANY so it will match the first template instead of the
one that actually intersects with the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=751235
