GitLab

This commit adds a .gitlab-ci.yml file, which uses a feature
to fetch the config from a centralized repository. The intent is
to have all the gstreamer modules use the same configuration.

The configuration is currently hosted at the gst-ci repository
under the gitlab/ci_template.yml path.

Part of gstreamer/gstreamer-project#29

Returned string should be freed

Fixes #319

Currently in Python it would become a signed 64 bit value but should
actually be an unsigned 32 bit value with all bits set.

This is the same problem as with GST_MESSAGE_TYPE_ANY.

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

We won't be able to do ASSERT_CRITICAL, but the main body of the tests
are still valid, and given we ship GStreamer with this configuration, it
is important to be able to run some tests against it.

In the previous configuration, mktime returned -1 on Windows 10 compiled
with MSVC using meson.

Fix this by moving the hour one forward.

Maybe the implementation should not be dependent on a "random" hash-table
ordering, but at least this shows the problem clearly.

If stderr is not redirected by the user, also page that.

By using these functions, we can shave off a few lines, and make the
intent of that line more clear.

Follow-up to !18 and #320.

This adds gdb pretty printer for some GStreamer types.
For GstObject pointers the type and name is added, e.g.
"0x5555557e4110 [GstDecodeBin|decodebin0]".
For GstMiniObject pointers the object type is added, e.g.
"0x7fffe001fc50 [GstBuffer]".
For GstClockTime and GstClockTimeDiff the time is also printed in human
readable form, e.g. "150116219955 [+0:02:30.116219955]".

Fixes #320

There's no need for it to be in the public struct and we can keep the
padding for things to be added in the future.

Allows determining from downstream what the expected bitrate of a stream
may be which is useful in queue2 for setting time based limits when
upstream does not provide timing information.

Implement bitrate query handling in queue2

gst-plugins-base#60

If upstream is pushing buffers larger than our limits, only 1 buffer
is ever in the queue at a time.  Once that single buffer has left the
queue, a 0% buffering message would be posted followed immediately by a
100% buffering message when the next buffer was inserted into the queue
a very short time later.  As per the recommendations, This would result
in the application pausing for a short while causing the appearance of
a short stutter.

The first step of a solution involves not posting a buffering message if
there is still data waiting on the sink pad for insertion into the queue.
This successfully drops the 0% messages from being posted however a
message is still posted on each transition to 100% when the new buffer
arrives resulting in a string of 100% buffering messages.  We silence
these by storing the last posted buffering percentage and only posting a
new message when it is different from or last posted message.

The post tracer hooks have a GstQuery argument which was truncated from
the trace. As the post hook is the one that contains the useful data,
this bug was hiding the important information from that trace.

By moving the functionality down to the testclock, the implementation
no longer needs to poll the waits, but rather wait properly for
them to be added.

The performance-hit here would be that by polling the test-clock
regularly, you would create contention on the testclock-lock, making code
using the testclock (gst_clock_id_wait) fighting for the lock.

Saves a lot of computations.

A pointer to a hook in this list can easily not be unique, given both
the slice-allocator reusing memory, and the OS re-using freed blocks
in malloc.

By doing many repeated add and remove of probes, this becomes very easily
reproduced.

Instead use hook_id, which *is* unique for a added GHook.

One restriction on the GBytes is that the data cannot be NULL as this is
explicitly forbidden by GstMemory.

Fixes gstreamer/gstreamer#318

g_clear_pointer is not thread-safe and never was. GLib similarly removed
the volatile from g_clear_object in 2aacef39b1.

Fixes #327

This makes its API consistent with the other GstMiniObject subclasses

This makes its API consistent with the other GstMiniObject subclasses

This makes its API consistent with the other GstMiniObject subclasses.

This makes its API consistent with the other GstMiniObject subclasses.

Basically, you can use this instead of using gst_structure_free (which
needs to be preceded by a NULL-check).

Also fixes #275

Basically, you can use this instead of using gst_tag_list_unref (which
needs to be preceded by a NULL-check).

Also fixes #275

Basically, you can use this instead of using gst_query_unref (which
needs to be preceded by a NULL-check).

Also fixes #275

Basically, you can use this instead of using gst_message_unref (which
needs to be preceded by a NULL-check).

Also fixes #275

Basically, you can use this instead of using gst_event_unref (which
needs to be preceded by a NULL-check).

Also fixes #275

Basically, you can use this instead of using gst_caps_unref (which
needs to be preceded by a NULL-check).

Also fixes #275

Basically, you can use this instead of using gst_buffer_list_unref
(which needs to be preceded by a NULL-check).

Also fixes #275

Basically, you can use this instead of using gst_buffer_unref (which
needs to be preceded by a NULL-check).

Also fixes #275

This is based on g_clear_object(). Basically, you can use this instead
of using gst_mini_object_unref (which needs to be preceded by a NULL-check).

Also fixes #275

This is based on g_clear_object(). Basically, you can use this instead
of using g_object_unref (which needs to be preceded by a NULL-check).

Fixes #275

This fixes #326

Based on a patch by Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>

Fixes gstreamer/gstreamer#67