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
Introduce a new operator ':' - e.g. element1 ':' element2
For example, 'uridecodebin : encodebin' -
if the encodebin has multiple profiles compatible with the
decodebin, multiple links will be created.
With '!' , after one delayed link is successfully done, the
pad-added callback is disconnected.
https://bugzilla.gnome.org/show_bug.cgi?id=751450
