* Don't mention explicitly that API is MT safe, this implies that
other API is not. GStreamer API is assumed to be MT safe, thread
safety should only be explicitly mentioned when API is *not* MT safe
* Don't repeat what annotations are stating with respect to ownership
transfer, nullability
* Document enumeration members in standalone comments, so that their
Since tag is accounted for by gobject-introspection
* Misc cleanup / typo fixes / addition of links
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/748>
* Don't mention explicitly that API is MT safe, this implies that
other API is not. GStreamer API is assumed to be MT safe, thread
safety should only be explicitly mentioned when API is *not* MT safe
* Don't repeat what annotations are stating with respect to ownership
transfer, nullability
* Document virtual methods in standalone comments, so that parameters
can be documented. This is not critical here, as parameters do not
need annotations / specific documentation, but serves as an up to
date example
* Document enumeration members in standalone comments, so that their
Since tag is accounted for by gobject-introspection
* Misc cleanup / typo fixes / addition of links
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/747>
GST_VALUE_HOLDS_... macros may cause -Waddress warning
on gcc if GValue is allocated on stack:
gstvalue.h:145:46: warning: the comparison will always
evaluate as ‘true’ for the address of ‘v’ will never
be NULL [-Waddress]
#define GST_VALUE_HOLDS_CAPS(x) ((x) != NULL &&
G_VALUE_TYPE(x) == _gst_caps_type)
Fixes#653
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/738>
Preserve the previous behaviour where:
name, val="5";
passed to gst_structure_from_string would have resulted in an int value,
rather than a string, despite the quote marks.
This will be changed to being interpreted as a string in the future, but
for the time being we will issue a warning about this to give users time
to fix their code to no longer rely on this bug.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/303>
Allow a string in gst_string_unwrap to include unescaped characters that
are not in GST_STRING_IS_ASCII. This extra leniency allows
gst_structure_from_string to, e.g., receive
name, val=(string)"string with space";
Note that many gst tests, and potentially users, exploited this behaviour
by giving
name, val="string with space";
i.e. without the (string) type specifier. This was allowed before
because, without a type specifier, the string was passed to
_priv_gst_value_parse_string with unescape set to TRUE, *rather* than
being sent to gst_string_unwrap. This caused a difference in behaviour
between strings that are or are not preceded by (string). E.g.
name, val=(string)"string with space";
would fail, whilst
name, val="string with space";
would not. And
name, val=(string)"\316\261";
would produce a val="α", whereas
name, val=(string)"\316\261";
would produce a val="316261" (a bug).
The current behaviour is to treat both of these cases the same, which is
desirable. But in order to not break potentially common usage of this
discrepancy (it was in our own tests), the best option is to make string
parsing less strict in general.
New behaviour would be for
name, val=(string)"string with space";
to pass and give val="string with space", and
name, val="\316\261";
would produce a val="α".
Also changed deserializing string test to expect successes where
previously a failure was expected.
In a similar way, this also effected the deserializing of GstStructure,
GstCaps, GstTagList and GstCapsFeatures. So, now
name, val=(structure)"sub-name, sub-val=(string)\"a: \\316\\261\";";
will also pass and give sub-val="a: α". Note that the quote marks
and backslash still need to be escaped for the sub-structure, but other
characters need not be.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/303>
No longer call _priv_gst_value_parse_string with unescape set to TRUE
before passing a value to gst_value_deserialize in
_priv_gst_value_parse_value. This latter function is called by
gst_structure_from_string and gst_caps_from_string.
When gst_structure_to_string and gst_caps_to_string are called, no
escaping is performed after calling gst_value_serialize. Therefore, by
unescaping the value string, we were introducing an additional operation
that was not performed by the original *_to_string functions. In
particular, this has meant that the derialization functions for many
non-basic types are incomplete reverses of the corresponding
serialization function (i.e., if you pipe the output of the
serialization function into the deserialization function it could fail)
because they have to compensate for this additional escaping operation,
when really this should be the domain of the deserialization functions
instead.
Correspondingly changed a few deserialization functions.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/452
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/303>
Until now we were enforcing that only 1 signal GSource was attached
the bus but we could attach as many GSource with `gst_bus_create_watch`
as we wanted... but in the end only 1 GSource will ever be dispatched for
a given `GstMessage` leading to totally broken behavior.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/718>
The GIR parser does not want any empty line after the function or macro
name line.
Fixes the following warning:
[309/4246] Generating Gst-1.0.gir with a custom command
../subprojects/gstreamer/gst/gstelement.h:57: Warning: Gst: "@element" parameter unexpected at this location:
* @element: The element name in lower case, with words separated by '_'.
^
../subprojects/gstreamer/gst/gstelement.h:84: Warning: Gst: "@e" parameter unexpected at this location:
* @e: The element name in lower case, with words separated by '_'.
^
../subprojects/gstreamer/gst/gstelement.h:106: Warning: Gst: "@e" parameter unexpected at this location:
* @e: The element name in lower case, with words separated by '_'.
^
../subprojects/gstreamer/gst/gstdeviceprovider.h:32: Warning: Gst: "@d_p" parameter unexpected at this location:
* @d_p: The device provider name in lower case, with words separated by '_'.
^
../subprojects/gstreamer/gst/gstdynamictypefactory.h:28: Warning: Gst: "@t_n" parameter unexpected at this location:
* @t_n: The dynamic type name in lower case, with words separated by '_'.
^
../subprojects/gstreamer/gst/gsttypefind.h:34: Warning: Gst: "@type_find" parameter unexpected at this location:
* @type_find: The type find name in lower case, with words separated by '_'.
^
../subprojects/gstreamer/gst/gsttypefind.h:61: Warning: Gst: "@t_f" parameter unexpected at this location:
* @t_f: The type find name in lower case, with words separated by '_'.
^
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/719>
This introduces a more human friendly syntax to specify nested
structures It does so by using 2 different markers for opening and
closing them instead of abusing quotes which lead to requiring an insane
amount of escaping to match nesting levels.
The brackets (`[` and `]`) have been chosen as they avoid complex
constructions with curly brackets (or lower/higher than signs) where you
could have structures embedded inside arrays (which also use curly
brackets), ie. `s, array=(structure){{struct}}` should be parsed as an
array of structures, but the cast seems to imply something different. We
do not have this issue with brackets as they are currently used for
ranges, which can only be casted to numeric types.
This commit does not make use of that new syntax for serialization as
that would break backward compatibility, so it is basically a 'sugar'
syntax for humans. A notice has been explicitly made in the
documentation to let the user know about it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/532>
The various wait implementation have a latency ranging from 50 to 500+
microseconds. While this is not a major issue when dealing with a low number of
waits per second (for ex: video), it does introduce a non-negligeable jitter for
synchronization of higher packet rate systems.
The `clock_nanosleep` syscall does offer a lower-latency waiting system but is
unfortunately blocking, so we don't want to use it in all scenarios nor for too
long.
This patch makes GstSystemClock use clock_nanosleep (if available) as such:
* Any wait below 500us uses it
* Any wait below 2ms will first use the regular waiting system and then
clock_nanosleep
# modified: gst/gstsystemclock.c
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/688>
While the default implementation will spawn a thread per new
pushed task, this new implementation instead spawns a maximum
number of threads, then queues new tasks on existing threads.
The thread that the new task will be queued on is picked in
a pretty naive fashion, by simply popping the first thread
from a queue and pushing it back to the tail, but this is
an implementation detail and can always be sophisticated
in the future if the need arises.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/692>
While the default implementation passes NULL around as the
task handle, other implementations can only provide a safe
API by having that handle map to a refcounted opaque type.
While what's passed around is a gpointer, a valid transfer
type annotation has informative value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/692>
When compiling for 32bit architectures with 64bit time_t e.g. riscv32,
the static assert that the GstClockEntryImpl smaller or
equal to the struct _GstClockEntryImpl triggered.
(they were 12bytes off).
To fix this, the padding is increased by 8 bytes (on 32bit).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/694>
If a device provider fails to start (for instance the pulseaudio provider unable
to connect to the PulseAudio daemon) then the monitor should not keep track of
it in its `started` providers list. Otherwise a false positive critical warning
would be raised.
This patch also switches the started_count type from bool to int, for
consistency. This is a counter, after all.
API: gst_device_provider_is_started
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/679>
In order to support the symbol g_enum_to_string in various
project using GStreamer ( gst-validate etc.), the glib minimum
version should be 2.56.0.
Remove compat code as glib requirement
is now > 2.56
Version used by Ubuntu 18.04 LTS
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/199>
Typing hints can only be passed to gst_value_deserialize()
through the type of the passed-in value. This means deserialization
can only target the desired type for the top-level elements,
making it for example impossible to deserialize an array of
flags to the expected type.
This commit exposes a new function, gst_value_deserialize_full(),
that takes an optional pspec as the extra parameter, and updates
the deserialization code to pass around that pspec, or the
element_spec when recursively parsing the elements of a list-type
value.
This allows for example passing arrays of flags through the
command line or gst_util_set_object_arg, eg:
foo="<bar,bar+baz>"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/629>
... and update meson file so that enable it only using required headers.
"dependency(...)" is unlikely successful for Windows SDK libraries
since it doesn't ship pkg-config file. So it needs to be changed
to "find_library()" to link corresponding .lib file. That would
result to most MSVC build system will link dbghelp.dll. However,
one drawback of the change is that gstreamer-1.0.dll will mandate
dbghelp.dll although it should be optional. So g_module_open() way
can be the most safe way in this case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/626>
Custom meta is backed by a GstStructure, and does not require
that users of the API expose their GstMeta implementation as
public API for other components to make use of it.
In addition, it provides a simpler interface by ignoring the
impl vs. api distinction that the regular API exposes.
This new API is meant to be the meta counterpart to custom events
and messages, and to be more convenient than the lower-level API
when the absolute best performance isn't a requirement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/609>
Subsequent lookups in the hashtable are probably better done
on memory we're confident is allocated to us :)
It was easy to trigger invalid reads by calling gst_meta_register
with dynamically allocated memory, freeing that memory, then
calling gst_meta_get_info()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/628>
663: Warning: Gst: symbol='GFLOAT_TO_LE': Unknown namespace for symbol 'GFLOAT_TO_LE'
664: Warning: Gst: symbol='GFLOAT_TO_BE': Unknown namespace for symbol 'GFLOAT_TO_BE'
665: Warning: Gst: symbol='GDOUBLE_TO_LE': Unknown namespace for symbol 'GDOUBLE_TO_LE'
666: Warning: Gst: symbol='GDOUBLE_TO_BE': Unknown namespace for symbol 'GDOUBLE_TO_BE'
669: Warning: Gst: symbol='GFLOAT_TO_LE': Unknown namespace for symbol 'GFLOAT_TO_LE'
670: Warning: Gst: symbol='GFLOAT_TO_BE': Unknown namespace for symbol 'GFLOAT_TO_BE'
671: Warning: Gst: symbol='GDOUBLE_TO_LE': Unknown namespace for symbol 'GDOUBLE_TO_LE'
672: Warning: Gst: symbol='GDOUBLE_TO_BE': Unknown namespace for symbol 'GDOUBLE_TO_BE'
678: Warning: Gst: symbol='GFLOAT_FROM_LE': Unknown namespace for symbol 'GFLOAT_FROM_LE'
679: Warning: Gst: symbol='GFLOAT_FROM_BE': Unknown namespace for symbol 'GFLOAT_FROM_BE'
680: Warning: Gst: symbol='GDOUBLE_FROM_LE': Unknown namespace for symbol 'GDOUBLE_FROM_LE'
681: Warning: Gst: symbol='GDOUBLE_FROM_BE': Unknown namespace for symbol 'GDOUBLE_FROM_BE'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
Easier to just make g-ir-scanner skip this header via #ifndef __GI_SCANNER__
than maintain different sets of headers in the meson.build file.
Warning: Gst: symbol="rint": Unknown namespace for symbol "rint"
Warning: Gst: symbol="rintf": Unknown namespace for symbol "rintf"
Warning: Gst: symbol="isnan": Unknown namespace for symbol "isnan"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
gstevent.h:72: Warning: Gst: symbol='FLAG': Unknown namespace for symbol 'FLAG'
gstquery.h:76: Warning: Gst: symbol='FLAG': Unknown namespace for symbol 'FLAG'
Use _FLAG(xyz) instead of FLAG(xyz) to silence g-ir-scanner
warnings about this internal helper define.
It's also slightly more hygienic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
It's been around for more than 4 years and people have built
lots of stuff on top of it, doesn't really make sense to keep
it marked as unstable. We're unlikely to change it now, and
we can always deprecate it and make a new one if needed.
This stabilises the following API:
- gst_tracer_register()
- gst_tracing_get_active_tracers()
- gst_tracing_register_hook()
- gst_tracer_record_new()
- gst_tracer_record_log()
Might also help a bit with #424
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/576>
The global seqnum variable wasn't actually increased in
the fallback code path, leading to all buffers getting
a seqnum of 0. Which also made the unit test fail.
This affects platforms/toolchains that don't have
64-bit atomic ops such as when compiling for armv7 rpi.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/565>
For providers that don't support dynamic probing, just fall back to doing
a static one on start() to make the UI developers life easier.
This also means that the monitor doesn't need to call _can_monitor() before
calling start.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/353>
In case a plugin filename was renamed with the plugin being in the registry cache
the features were not loaded after the rename:
1) Cache of old/gone filename was loaded, features added
2) New filename was loaded, features where not added because
they were already found in the registry.
3) In the end stale cache entries for files which are no longer there
are removed, including the wanted features.
4) The cache gets updated without the features.
Fix this by also checking at (2) that the found feature is from the loaded plugin
and not from some stale cache entry.
This affected directsoundsink where libgstdirectsoundsink.dll was renamed
to libgstdirectsound.dll, losing the directsoundsink element in the process.
Fixes#290
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/102>
Otherwise the proxy pad of the ghost pad still stays linked to some
element inside the bin, which is not allowed anymore according to the
topology.
In 2.0 this should be fixed more generically from inside GstGhostPad but
currently there is no way to get notified that the ghost pad is
unparented.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/553>
There is a race-condition that can trigger the assertion in
gst_bus_add_signal_watch_full():
If gst_bus_add_signal_watch_full() is called immediately after
gst_bus_remove_signal_watch() then bus->priv->signal_watch may still be set
because gst_bus_source_dispose() or gst_bus_source_finalize() was not yet
called.
This happens if the corresponding GMainContext has the source queued for
dispatch. In this case, the following dispatch will only unref and delete
the signal_watch because it was already destroyed. Any pending messages
will remain until a new watch is installed.
So bus->priv->signal_watch can be cleared immediately when the watch is
removed. This avoid the race condition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/543>
Instead do everything it did as part of GObject::constructed() and
change the function to always return TRUE.
gst_ghost_pad_construct() was meant to be called by subclasses right
after construction of the object to finish construction as it can fail
in theory. In practice it's impossible for it to fail, even more so if
called directly from GObject::constructed(): The only failure condition
is if the newly created proxy pad already has a parent, which is
impossible at this point as nothing else can have a reference to it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/540>
Since glib 2.64, gthreadpool will start waiting on a GCond immediately upon
creation. This can cause issues if we fork *before* actually using the
threadpool since we will then be signalling that GCond ... from another process
and that will never work.
Instead, delay creationg of thread pools until the very first time we need
them. This introduces a minor (un-noticeable) delay when needing a new thread
but fixes the issues for all users of GSTreamer that will call gst_init, then
fork and actually start pipelines.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2131 for more context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/531>
When compiling for 32bit ios arm, the static assert that the
GstClockEntryImpl smaller or equal to the struct _GstClockEntryImpl
triggered. (they were 12bytes off).
To fix this, the padding is increased by 12 bytes (on 32bit).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/525>
These can be passed to gst_type_mark_as_plugin_api, to inform
plugin cache generation.
For now a single flag is specified, "IGNORE_ENUM_MEMBERS", it
can be used for dynamically generated enums to avoid documenting
environment-specific enumeration members. An example is
GstX265EncTune.
