GitLab

gst/gstprintf unit test would fail on 32-bit x86 with:
gstprintf.c:83:printf_I32_I64:0: 'str' (64-bit x value = b5a6978f) is not equal to '"64-bit x value = f1e2d3c4b5a6978f"'

This reverts commit cfc565e2.

The commit was redundant since gst_gen_sources already contains
gstenum_h. We're still investigating why some people are still seeing
a racy build failure.

This forces gstenumtypes.h to be built whenever something uses gst_dep
as a subproject dependency. This is needed since gst/gst.h includes
gstenumtypes.h

Closes https://github.com/mesonbuild/meson/issues/714 which is not
actually a Meson bug.

Need to cast away the const as g_queue_foreach() takes a non-const GQueue*

Otherwise both iterators share the same references, the second one
usually resulting in a crash when being freed.

https://bugzilla.gnome.org/show_bug.cgi?id=771649

This carries over code for a similar test from multiqueue to ensure full
control over the dataflow while testing. (The previous attempt was racy
since the fill level changed without any thread sync with the test code.)

https://bugzilla.gnome.org/show_bug.cgi?id=771210

https://bugzilla.gnome.org/show_bug.cgi?id=771210

Seems like there was some documentation left over from when this was
gst_message_new_duration().

basesink: Remove unused fields and always use the buffer timestamp difference for calculating the QoS proportion

The buffer timestamps are only hints and more often than not have
nothing to do with reality.

https://bugzilla.gnome.org/show_bug.cgi?id=771306

Earlier we were only using __declspec(dllexport/import) when we were
built with MSVC because when built with MinGW and linking with MinGW we
don't need it (and we get linker errors because of it).

However, when we're built with MinGW and someone wants to link to us
with MSVC, we still need the prototypes to have __declspec(dllimport)
since MSVC cannot do auto-import like GCC can.

https://bugzilla.gnome.org/show_bug.cgi?id=771029

Otherwise our bin might lose various flags that were explicitly set on
it at arbitrary times.

Some simple tests to make sure it keeps working

Suppress-flags is for preventing propagation of child element's specific
flag when it is added to the bin.

https://bugzilla.gnome.org/show_bug.cgi?id=770627

From b18d820 to f980fd9

Otherwise GST_TYPE_FRACTION will work correctly in tags.

https://bugzilla.gnome.org/show_bug.cgi?id=753922

When using seek_simple() in combination with other kinds of seeks, this
becomes problematic. seek_simple() does not reset the stop position to
GST_CLOCK_TIME_NONE but keeps whatever a previous seek did. So for example
when doing a seek_simple() after a rate=-1 seek, we would usually get
assertions that start>stop (and stop being the old stop from the rate=1 seek).

https://bugzilla.gnome.org/show_bug.cgi?id=771104

From f49c55e to b18d820

Basically we already have each test with a 20sec timeout,
and testsuite can last more than the default 30secs from
meson. 3 minutes is another arbitrary timeout but should
be good enough.

basesink: Use the average durations based on timestamps for the QoS proportion when doing trickmodes

The durations of the buffers are (usually) assuming that no frames are being
dropped and are just the durations coming from the stream. However if we do
trickmodes, frames are being dropped regularly especially if only key units
are supposed to be played.

Fixes completely bogus QoS proportion values in the above case.

And add a way to disable the introspection and bump version to 1.9.2

https://bugzilla.gnome.org/show_bug.cgi?id=770731

__ppc__ and __ppc64__ are non-standard defines, we should use
__powerpc__ and __powerpc64__ instead because newer gcc doesn't know
them anymore.

Print GObject argument properly with pointer marker:

  "client-added" :  void user_function (GstElement* object,
                                        GObject* arg0,
                                        gpointer user_data);

instead of

  "client-added" :  void user_function (GstElement* object,
                                        GObject arg0,
                                        gpointer user_data);

for gst-inspect-1.0 tcpserversink.

https://bugzilla.gnome.org/show_bug.cgi?id=770740

low/high-watermark are of type double, and given in range 0.0-1.0. This
makes it possible to set low/high watermarks with greater resolution,
which is useful with large multiqueue max sizes and watermarks like 0.5%.

Also adding a test to check the fill and watermark level behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=770628

To make the code clearer, and to facilitate future improvements, introduce
a distinction between the buffering level and the buffering percentage.

Buffering level: the queue's current fill level. The low/high watermarks
are in this range.

Buffering percentage: percentage relative to the low/high watermarks
(0% = low watermark, 100% = high watermark).

To that end, get_percentage() is renamed to get_buffering_level(). Also,
low/high_percent are renamed to low/high_watermark to avoid confusion.
mq->buffering_percent values are now normalized in the 0..100 range for
buffering messages inside update_buffering(), and not just before sending
the buffering message. Finally the buffering level range is parameterized
by adding a new constant called MAX_BUFFERING_LEVEL.

https://bugzilla.gnome.org/show_bug.cgi?id=770628

This is a prerequisite for subsequent commits, and makes queue2 and
multiqueue code a little more consistent.

https://bugzilla.gnome.org/show_bug.cgi?id=770628

When calculating the high_time, cache the group value in each singlequeue.

This fixes the issue by which wake_up_next_non_linked() would use the global
high-time to decide whether to wake-up a waiting thread, instead of the group
one, resulting in those threads constantly spinning.

Tidy up a bit the waiting logic while we're at it.

With this patch, we go from 212% playing a 8 audio / 8 video file down to less
than 10% (most of it being the video decoding).

https://bugzilla.gnome.org/show_bug.cgi?id=770225

This just confuses people, they look at it and try to call it
directly by name, instead of using the public GstElement API.
It stands to reason that it goes without saying that when an
element provides request pads that they can actually be
requested using the standard API, and there's no point in
printing internal implementation details of the element.

https://bugzilla.gnome.org/show_bug.cgi?id=770158

In many parts of the code we raise streaming error when the flow
goes wrong, and each time we create more or less similare error
message. Also that message does not let the application know what
has actually gone wrong. In the new API we add a "flow-return" detail
field inside the GstMessage so that the application has all the information
if it needs it.

API:
    GST_ELEMENT_FLOW_ERROR

https://bugzilla.gnome.org/show_bug.cgi?id=770158

We only use GST_EXPORT consistently when building with MSVC by using the
visual studio definitions files (win32/common/*.def), so always disable
it when building with Autotools and only enable it with Meson when
building with MSVC.

This allows you to use MinGW to link to a GStreamer built with MSVC and
get the correct function prototypes to find functions and variables in
DLLs.

https://bugzilla.gnome.org//show_bug.cgi?id=770428

Fixes g-i warning "Gst: Constructor return type mismatch
symbol='gst_element_message_new_details' constructed='Gst.Element'
return='Gst.Structure'".

This is a newly-added function in git that has not been in a stable
release yet, so it's fine to rename it. It's also only used indirectly
via macros.

e.g. "warning: multi-line since docs found"