This is something bindings can't handle and it causes leaks. Instead
move the ref_sink() to the explicit, new() constructors.
This means that abstract classes, and anything that can have subclasses,
will have to do ref_sink() in their new() function now. Specifically
this affects GstClock and GstControlSource.
https://bugzilla.gnome.org/show_bug.cgi?id=743062
If a function takes a floating reference parameter, it should also be
sinked in error cases. Otherwise the function behaves differently
between error and normal cases, which is impossible for bindings to
handle.
https://bugzilla.gnome.org/show_bug.cgi?id=747990
If a function takes a floating reference and sinks it, it should also do
that in error cases. I.e. call ref_sink() followed by unref().
Otherwise the reference counting behaviour of the function will be
different between the good and the error case, and simply inconsistent.
https://bugzilla.gnome.org/show_bug.cgi?id=747990
Can't use a #ifndef GST_DISABLE_DEPRECATED guard around deprecated
functions any more, as they won't get exported then. Besides, we
get a nicer error message from the compiler telling us what function
to use instead this way.
This is a meta that generically allows to attach additional reference
timestamps to a buffer, that don't have to relate to the pipeline clock
in any way.
Examples of this could be an NTP timestamp when the media was captured,
a frame counter on the capture side or the (local) UNIX timestamp when
the media was captured.
https://bugzilla.gnome.org/show_bug.cgi?id=779213
This is useful for integration with other event loops that work by
polling file descriptors. G_IO_IN will always be set whenever a message
is available currently.
https://bugzilla.gnome.org/show_bug.cgi?id=776126
This patch changes the entry point of each plugin in order to unify the
interface for static and dynamic plugin. What we do is replace the
current static plugin interface and extend the dymamic one. The plugin
entry was a C structure, name "gst_plugin_desc". With this patch, the
interface is now:
GstPpluginDesc *gst_plugin_<name>_get_desc(void);
The reason we change the C structure into function, is that it is
potentially more common to have function pointers, avoiding possible
binding language limitation. Additionally to that. This change prevents
the symbols from clashing between plugins, allowing to build once the
plugin (assuming you have -fPIC).
On the plugin loader side, we symply derive the shared object basename
to extract the plugin name. If this symbol is not found, we fallback to
gst_plugin_desc for backward compatibility.
This has one side effect, which is that the shared objects now need to
be named after their plugin name. This is generally the case with few
exceptions. The benifit of this limitation is that you can control the
gst_plugin_<name>_desc clash at file level.
https://bugzilla.gnome.org/show_bug.cgi?id=779344
It is possible to use gst_deinit() without registering the base
classes. For example, when using gst_init_get_option_group() and
call the program with an invalid parameter. In that case,
gst_deinit() will lead to a segmentation fault, since there is a
dereference to a pointer that is null.
This patch validates if the type is non-null before dereferencing
it.
https://bugzilla.gnome.org/show_bug.cgi?id=781914
Use g_object_new() instead which nowadays has a shortcut for the
no-properties check. It still does an extra GType check in the
function guard, but there's a pending patch to remove that
and it's hardly going to be a performance issue in practice,
even less so on a system that's compiled without run-time checks.
Alternative would be to move to the new g_object_new_properties()
with a fallback define for older glib versions, but it makes the
code look more unwieldy and doesn't seem worth it.
Fixes deprecation warnings when building against newer GLib versions.
https://bugzilla.gnome.org/show_bug.cgi?id=780903
They were (signed!) gint64 before because of G_GINT64_CONSTANT() already
and they are actually used in signed calculations.
With this change we at least ensure that an integer type of the correct
size is used for GI (it was using gint before).
The issue happens when the structure is printed by the logging
subsystem: the object is included in the log, and this will cause the
full object printout to be done there. However, after dispose, the queue
was already cleared, so the access to it (to print the object) would
assert, as the queue was already freed. The patch changes it so that the
queue is merely empty, and only freed in _finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=776293
A paramspec validation should modify the content to match what the spec
requires and return TURE if a modification happened. This previous
implementation would only fix the first element of the array and return.
It was also return TRUE for empty array, while no modification was
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=780111
The GST_TYPE macro points to global variables initialized by the
first call to get_type. This is not an issue if you call gst_init()
but unfortunatly pygi will need to acces the param type before
init can be called. This removes an assertion.
Those aren't suppose to be called from multiple thread, but all
fundamental get_type() function are thread safe. Fix it to
be consistent and it may help if we change the typing mechanism
in GStreamer come day.
This is to help bindings access properties of type GST_TYPE_ARRAY.
This function will get/set the property and convert form/to
GValueArray.
New API:
gst_util_set_object_array
gst_util_get_object_array
https://bugzilla.gnome.org/show_bug.cgi?id=753754
This adds a binding friendly interface to get and set arrays
and list into GstStructure.
New API:
- gst_structure_set_array
- gst_structure_set_list
- gst_structure_get_array
- gst_structure_get_list
https://bugzilla.gnome.org/show_bug.cgi?id=753754
When registering GstParamSpecArray, use the gst_value_array_get_type()
function to get the type, rather than the GST_TYPE_ARRAY macro, which
gets it from the _gst_value_array_type, which is in turn only
initialised during gst_init()
Fixes criticals with (python) bindings that look up all the
types from the gobject-introspection info as soon as they
are imported.
/usr/lib64/python3.5/site-packages/gi/module.py:178: Warning: g_param_type_register_static: assertion 'g_type_name (pspec_info->value_type) != NULL' failed
g_type = info.get_g_type()
/usr/lib64/python3.5/site-packages/gi/module.py:212: Warning: g_type_get_qdata: assertion 'node != NULL' failed
type_ = g_type.pytype
/usr/lib64/python3.5/site-packages/gi/module.py:226: Warning: g_type_get_qdata: assertion 'node != NULL' failed
g_type.pytype = wrapper
/usr/lib64/python3.5/site-packages/gi/module.py:226: Warning: g_type_set_qdata: assertion 'node != NULL' failed
g_type.pytype = wrapper
If guessing that a string matches a flagset, be more thorough
at checking that the string following a string of hex:hex:
actually looks like a flag set string. Add some unit tests
to catch more cases.
https://bugzilla.gnome.org/show_bug.cgi?id=779755
But only when serializing outside of GstStructures, because in case of
GstStructure the type is already preprended to the array/list and the
GstStructure API makes sure that they have the same "generic" type so
deserialization works properly.
This keeps serialization of GstStructures the same as before, and the
GstCaps unit tests already test for that. However when serializing
standalone arrays/lists get the types added now.
This can easily deadlock if the element uses the object lock for
something internally, like posting an error message. Use an GstIterator
for iterating over the pads instead.
https://bugzilla.gnome.org/show_bug.cgi?id=777449
When registering a new debug category after _debug_init(), we need to
re check the GST_DEBUG filter settings again.
In addition when parsing the filter setting, we need to already bump up
the min-debug level to not suppress debug log statments that dynamically
register a category. This happens in libraries that use a function to
register a category on first use.
A property not defined in a preset file can simply mean that the
user wants it to be set as it default value, and we should not warn
about that.
A missing preset file in a directory can happen has there are several
directory where a preset can be found in.
Saves us a custom script. Template files are nicer than passing
multiline templating stuff through to glib-mkenums. And we can
get rid of our custom python script.
It's a programming error to pass other pads here, and it easily causes
crashes or other problematic behaviour down the road as subclasses
usually assume to only get their pads.
Allows proper usage of structures in structures in caps. Subtraction
is not implemented due to complications with empty fields representing
all possible values.
The only implementation that doesn't delegate to the already existing
GstStructure functions is the union function.
https://bugzilla.gnome.org/show_bug.cgi?id=775796
After b76ecfd992 introduced
GST_PAD_FLAG_ACCEPT_TEMPLATE, the performance penalty this
message is refering to (the cascading ACCEPT_CAPS query)
only applies to the cases where !GST_PAD_IS_ACCEPT_TEMPLATE
This is an API break but that API has not been released yet.
We are passing a flag rather than a simple boolean as we can imagine
to implement more features in the future for example to retrieve a
stack trace for all the threads, etc..
Retrieving source file and line numbers is pretty
expensive while getting a stack trace, this new argument
allows the user to decide to retrieve a backtrace
without those infos instead which is much faster.
For example running $ GST_LEAKS_TRACER_STACK_TRACE=1 GST_DEBUG=GST_TRACER:7 \
GST_TRACERS=leaks time gst-launch-1.0 videotestsrc num-buffers=1 ! fakesink:
* With simple stack traces:
0.04s user 0.02s system 99% cpu 0.060 total
* With full stack traces:
0.66s user 0.23s system 96% cpu 0.926 total
https://bugzilla.gnome.org/show_bug.cgi?id=775423
