This reverts commit fc5cd959.

* Document virtual methods in standalone comments, in order to properly
  annotate them

* Don't repeat what annotations are stating with respect to ownership
  transfer, nullability

* Mark GstControlBinding ABI field as private

* Misc cleanup / typo fixes / addition of links

Part-of: <!758>

Mathieu Duponchelle authored Feb 12, 2021 and GStreamer Marge Bot committed Feb 15, 2021

* 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: <!756>

_GST_ELEMENT_REGISTER_DEFINE_BEGIN
_GST_ELEMENT_REGISTER_DEFINE_END was introducing
an extra extern "C" in case of c++ build.

Add missing ";" in GST_ELEMENT_REGISTER_DECLARE

Part-of: <!757>

* 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

* Document virtual methods in standalone comments, in order to properly
  annotate them

* Don't repeat what annotations are stating with respect to ownership
  transfer, nullability

* Misc cleanup / typo fixes / addition of links

Part-of: <!755>

* Don't repeat what annotations are stating with respect to ownership
  transfer, nullability

* Reword the warnings for caps nestability in light of the 1.20
  improvements

* Misc cleanup / typo fixes / addition of links

Part-of: <!754>

Add a test that removing a blocking probe on events when there
is a different blocking probe on buffers releases the data flow.

Part-of: <!749>

Explain that GST_PAD_PROBE_PASS will pass data even if there is
another pad probe that says to block, and that GST_PAD_PROBE_REMOVE
passes data and potentially unblocks the pad.

Part-of: <!749>

Change the way the marshalled flag in the internal ProbeMarshall state
is handled when iterating over pad probes so that it only counts
probes that still exist and would be called when retrying.

This improves the way that removing a blocking probe works when
there are multiple blocking probes for different conditions (data vs
events for example).

As a side-effect, probes aren't put into the the called_probes array
unless they actually match the current probe type and would be called,
potentially reducing the number of hooks that get stored in the
called_probes array, and the cost of the looping check on retries.

Fixes #658

Part-of: <!749>

* 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 and the class structure

* Misc cleanup / typo fixes / addition of links

Part-of: <!753>

* 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 functionally useful here, as parameters
  require annotations, and should make the class more usable by
  bindings.

* Misc cleanup / typo fixes / addition of links

Part-of: <!752>

* Don't repeat what annotations are stating with respect to ownership
  transfer, nullability

* Misc cleanup / typo fixes / addition of links

Part-of: <!752>

Part-of: <!752>

* 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: <!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: <!747>

Part-of: <!747>

In particular, there is no need to explicitly mention free
functions / ownership transfers, this should be obvious from
the annotations.

Part-of: <!745>

The default ordering is alphabetical, causing GstAllocationParams
to appear first in the page if left auto-sorted

Part-of: <!745>

Part-of: <!745>

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

Part-of: <!744>

Part-of: <!742>

Aleksandr Slobodeniuk authored Jan 25, 2021 and GStreamer Marge Bot committed Jan 28, 2021

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>

Chris White authored Dec 24, 2020 and Thibault Saunier committed Jan 19, 2021

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

Part-of: <!303>

Henry Wilkes authored Oct 28, 2019 and Thibault Saunier committed Jan 19, 2021

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>

Henry Wilkes authored Oct 23, 2019 and GStreamer Marge Bot committed Jan 19, 2021

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>

Henry Wilkes authored Oct 18, 2019 and GStreamer Marge Bot committed Jan 19, 2021

Added tests to ensure that the gst_value_deserialize reverses
gst_value_serialize.

Part-of: <!303>

Henry Wilkes authored Oct 18, 2019 and GStreamer Marge Bot committed Jan 19, 2021

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>

Seungha Yang authored Jan 15, 2021 and GStreamer Marge Bot committed Jan 14, 2021

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>

Marijn Suijten authored Jan 14, 2021 and Sebastian Dröge committed Jan 14, 2021

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

Part-of: <!725>

Michael Tretter authored Oct 23, 2020 and GStreamer Marge Bot committed Dec 22, 2020

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>

Fredrik Pålsson authored Dec 12, 2020 and Fredrik Pålsson committed Dec 20, 2020

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>

Thibault Saunier authored Dec 10, 2020 and GStreamer Marge Bot committed Dec 11, 2020

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>