gst_structure_id_get() returns a new reference so the returned device is
actually (transfer full).
The code using this API was already correct but the code example in
comments was not.
https://bugzilla.gnome.org/show_bug.cgi?id=768776
When GST_PAD_PROBE_EVENT_FLUSH is used, the probes already have
a data type and it is not needed to automatically add the default
types. Without this, EVENT_FLUSH probes that didn't specify a data
type would be called also for other data such as buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=762330
Make it explicit that the pad is only blocked while the callback is running,
and the pad will be unblocked again once the callback returned.
If BLOCK and IDLE behaviour is needed, both need to be used.
https://bugzilla.gnome.org/show_bug.cgi?id=766002
When doing a transition from PLAYING to PLAYING, we will fail
to forward an EOS message on the bus, and noone else will ever
send it because there'll be no actual state changed message.
Allow EOS through directly in that case.
When activating a pad in PULL mode, it might already be in PUSH mode. We now
first try to deactivate it from PUSH mode and then try to activate it in PULL
mode. If the activation fails, we would set the pad to flushing and set it
back to its old mode. However the old mode is wrong, the pad is not in PUSH
mode anymore but in NONE mode.
This fixes e.g. typefind in decodebin reactivating PUSH/PULL mode if upstream
actually fails to go into PULL mode after first PUSHING data to typefind.
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.
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
