This stores debug logs in memory per thread and uses up to a
configurable amount of bytes per thread for the logs. Inactive threads
are timed out after a configurable amount of time.
https://bugzilla.gnome.org/show_bug.cgi?id=785035
Add back function guard that checks the refcount in a read-only
operation first, and bail out without modifying the passed-in
memory if it's clearly not a valid mini object. Otherwise we
probably cause more harm than good. We keep the second sanity
check based on the 'real refcount' at the time of the unref
around for now too.
https://bugzilla.gnome.org/show_bug.cgi?id=784383
gst_protection_filter_systems_by_available_decryptors() takes an array
of strings and returns a new array of strings filtered by the available
decryptors for them so the ones you get are the ones that you should be
able to decrypt.
https://bugzilla.gnome.org/show_bug.cgi?id=770107
Need to pass -DGST_DISABLE_DEPRECATED to avoid warnings when
testing deprecated API such as gst_uri_construct().
Also remove #ifndef GST_DISABLE_DEPRECATED guard from header
file, we don't use those any more for functions, the
GST_DEPRECATED_FOR macro is enough.
The gst_uri_construct function was escaping the location string
as a generic uri string. This is incorrect since the slash('/')
characters are reserved for use in this exact case. The patch
changes the escape_string function mode to handle the path correctly.
I have deleted the escape_string function since it is no longer being
used and have created a unit test for the function. I have also
deprecated this function in favour of the GstUri API.
https://bugzilla.gnome.org/show_bug.cgi?id=783787
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
As an usecase of URI fragment, it can indicate temporal or spatial
dimension of a media stream. To easily parse key-value pair,
newly added gst_uri_get_media_fragment_table () API will provide
the table of key-value pair likewise URI query.
See also https://www.w3.org/TR/media-frags/https://bugzilla.gnome.org/show_bug.cgi?id=774830
We were creating a new session to retrive each line of a stack trace
and we are supposed to start it once for a whole stack trace.
And pass the whole file to gst-indent.
https://bugzilla.gnome.org/show_bug.cgi?id=775365
This structure is always allocated by GStreamer, can't be
subclassed or extended, and is never allocated or used on
the stack, so we don't need any padding and can extend it
as we please.
When requesting a pad from a template and it's already linked, this
means it was a static pad. Since we only want to return an *available*
pad, we must return NULL ... but we must also remove the reference
we got from getting that static pad.
The "No need to unref" message (which wasn't true for quite some time)
dates back from the very very very first commit introducing the 0.10
features.
The caller might pass arbitrary data here that caused the error, and
trying to set invalid UTF-8 in a GstStructure causes it to be not set at
all. Later when trying to parse it, the field will not exist and the
return value will point to invalid memory. Prevent this by storing NULL
instead.
Also print a g_warning(), the caller should never ever do this to begin
with.
Add unit test to ensure that.
It can be a normal execution path to do some map trials and there is
no need to worry the user in that case.
The application has to check the return value of gst_memory_map.
https://bugzilla.gnome.org/show_bug.cgi?id=765600
To make sure the value is only expanded/used once, in case
there are side effects to it, and to avoid calculating it
or looking it up multiple times if there is a calculation
or lookup involved.
MSVC warns on this and the documentation about the warning says:
> The compiler assumes the function returns a value of type int
which is a little scary, so lets just remove the unnecessary 'return'
https://bugzilla.gnome.org/show_bug.cgi?id=774293
gstpoll.c: In function 'release_event':
gstpoll.c:239:3: error: suggest parentheses around assignment used as
truth value [-Werror=parentheses]
if (status = WaitForSingleObject (set->wakeup_event, INFINITE)) {
^~
https://bugzilla.gnome.org/show_bug.cgi?id=774108
