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
A pointer to a hook in this list can easily not be unique, given both
the slice-allocator reusing memory, and the OS re-using freed blocks
in malloc.
By doing many repeated add and remove of probes, this becomes very easily
reproduced.
Instead use hook_id, which *is* unique for a added GHook.
This is based on g_clear_object(). Basically, you can use this instead
of using gst_mini_object_unref (which needs to be preceded by a NULL-check).
Also fixes#275
If a segment has stop == -1, then gst_segment_to_running_time()
would refuse to calculate a running time for negative rates,
but gst_segment_do_seek() allows this scenario and uses a
valid duration for calculations.
Make the 2 functions consistent by using any configured duration
to calculate a running time too in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=796559
GST_TIME_FORMAT, GST_TIME_ARGS, GST_STIME_FORMAT, GST_STIME_ARGS
GST_PTR_FORMAT, GST_SEGMENT_FORMAT, GST_FOURCC_FORMAT and
GST_FOURCC_ARGS are format specifiers.
They can't be used outside of C and should be generated in the gir.
https://bugzilla.gnome.org/show_bug.cgi?id=797320
The Harware factory type classifier allows elements (decoders and encoders,
mostly) to advertize they rely on hardware devices to perform encoding or
decoding operations. This classifier can be used by applications to filter and
select only the elements that use hardware devices, for instance to ensure
zero-copy support is enabled for a specific pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=796921
In some cases the system protection ID is not present in the contents
or in their metadata.
This define is used to set the value of the "system_id" field in GstProtectionEvent,
with this value, the application will use an external information to choose which
protection system to use.
Example: The matroskademux uses this value in the case of encrypted WebM,
the application will choose the appropriate protection system based on the information
received through EME API.
https://bugzilla.gnome.org/show_bug.cgi?id=797231
The documentation incorrectly used to state that the pads were
not automatically activated when added, whereas we actually do
that when appropriate.
Callers of gst_element_add_pad must not hold the object lock,
which implies that they cannot perform the same checks as
add_pad in a non-racy manner.
This updates the documentation, and removes the g_warning
that was output before performing automatic activation.
https://bugzilla.gnome.org/show_bug.cgi?id=797181
Add new GST_API_EXPORT in config.h and use that for GST_*_API
decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
