GitLab

Part-of: <gstreamer/gstreamer!736>

Part-of: <gstreamer/gstreamer!736>

There should be no more cross-CRT issue on Windows since we bumped
MinGW toolchain

Part-of: <gstreamer/gstreamer!744>

Part-of: <!742>

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: <!738>

Shows the issue described in
<!303 (comment 272629)>

Part-of: <!303>

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: <!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: <!303>

Added tests to ensure that the gst_value_deserialize reverses
gst_value_serialize.

Part-of: <!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 #452

Part-of: <!303>

Since Windows 10 1607, we can make use of SetThreadDescription() API
for setting thread name. Unlike previously used exception based
method, this API will preserve configured thread name on dump file.

Part-of: <!735>

This reduces the chance of the main thread getting starved while trying
to shut down the test, potentially causing a timeout.

Even on an idle 96-processor system this reduces the duration of the
systemclock tests from ~8s to ~3s.

Part-of: <!734>

Part-of: <!730>

Part-of: <!730>

This parameter is only informational and should not be modified. Enforce
this at compile-time and to get the right signature in G-IR.

Part-of: <!730>

Follow-up from !728

Part-of: <!732>

Provide non-inline version of refcounting APIs so that it can be
consumed by bindings

Fixes: gstreamer-sharp#46
Part-of: <!728>

Part-of: <gstreamer/gstreamer!727>

Part-of: <!725>

The pipeline posts messages on the bus even if an application does not
handle the messages. This is expected behavior but may leak messages if
the messages are not handled.

Clarify the documentation.

Part-of: <!680>

Part-of: <!722>

GstHarness is not a GObject. Fixes assert on recently added check in
gst_debug_log_valist() if GST_ENABLE_EXTRA_CHECKS is enabled.

Part-of: <!720>

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: <!718>

Since GLib 2.36 we do not need it.

Part-of: <!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:...

Part-of: <!717>

Split plugin into features including
dynamic types which can be indiviually
registered during a static build.

More details here:

gstreamer/gst-build!199
gstreamer/gstreamer!661

Part-of: <gstreamer/gstreamer!661>

This macros will help to register a dynamic type
apart from a given plugin such as in a static build
of gstreamer where libgstreamer-full is generated.

Part-of: <!661>

This macros will help to register a device provider
apart from a given plugin such as in a static build
of gstreamer where libgstreamer-full is generated.

Part-of: <!661>

This macros will help to register a device provider
apart from a given plugin such as in a static build
of gstreamer where libgstreamer-full is generated.

Part-of: <!661>

Define separate macros to define an element
apart from the plugin itself.
These macros will help to register
elements a part from a plugin.
By example in the case of a gstreamer static build
producing the libgstreamer-full library.

More details here:

gst-build!199

Part-of: <!661>

with the option --sort, the output is sort by default
with alphabetical order with plugins and features.

Part-of: <!709>

Part-of: <!706>

g_time_zone_new() returns UTC if it fails to parse the timezone
identifier, which is rather suboptimal and causes wrong datetimes to be
created silently.

Part-of: <!706>

And also don't crash dereferencing a NULL pointer if the GDateTime
functions return NULL.

Fixes gstreamer/gstreamer#632

Part-of: <gstreamer/gstreamer!706>

This is more bindings friendly than requiring a special function to be
called beforehand or getting an assertion instead, and should also
simplify some usage.

Part-of: <gstreamer/gstreamer!706>

Part-of: <gstreamer/gstreamer!706>

This adds `gst_structure_serialize` and `gst_caps_serialize` which use
the newly introduced bracket delimiters for nested structures.

Part-of: <!532>

Part-of: <gstreamer/gstreamer!532>

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: <gstreamer/gstreamer!532>