Existing test for iterating/removing buffer meta data was insufficient
to detect linked list corruption when removing multiple items, and could
also suffer from such corruption in attempting to count remaining items.
Modified the one test and added several others to exercise multiple
scenarios.
Validates fix for issue #332.
Fix corruption of meta list head when removing metas at the beginning
during iteration. Linked list handling in gst_buffer_foreach_meta
failed to track the previous entry and update the correct next pointer
when removing items from beyond the head of the list, resulting in
arbitrary list pointer corruption.
Closes#332
baseparse internally uses a 64kb buffer for pulling data from upstream.
If a 64kb pull is failing with a short read, it would previously pull
again the requested size.
Doing so is not only inefficient but also seems to cause problems with
some elements (rawvideoparse) where the second pull would fail with EOS.
Short reads are only allowed in GStreamer at EOS.
Closes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/294
By doing so GL source elements can successfully reuse the GL context and display
of downstream elements. This change fixes an issue in playbin when using
gltestsrc where the context query made by the source element would fail and the
source element would create a second (useless) GLDisplay.
Not only this will make colored output work on old terminals and console
as well, terminals can theme the actual colors this way to make it fit
with their different themes this way.
Without this bindings get confused about the meaning of references, and
we really own these references if they are not already owned by
something else.
Let's make the output a bit pretty to read. The colored output can be
disabled with `--no-colors` option or by setting `GST_INSPECT_NO_COLORS'
env (to any value).
The chosen colors are based on the popular Solarized theme, which is
targeted for both dark and light backgrounds.
Note:
* We only support true colors. If the terminal doesn't signal support for
that via 'COLORTERM' env, we disable colored output.
* We don't add colors to --print-plugin-auto-install-info output, as
that's meant for machines, not humans. Not only machines don't care
about beauty, the existing ones will likely not expect colors and choke
on it and we'll get angry mob at our doors.
[1] https://ethanschoonover.com/solarized
When printing info about a specific plugin, there is no need to prefix
some of the details with plugin's name. It's not only redundant but also
inconsistent and makes the task of adding consistent coloring to the
output (which we'll do in a follow patch), harder.
This emulates the default behaviour of git help pages, and also fixes
a bug on macOS where `less -F` doesn't display anything at all when
the output is shorter than one terminal screen.
Also moved the DEFAULT_PAGER define to after the includes, because
it's an unprefixed define.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/330
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 https://gitlab.freedesktop.org/gstreamer/gstreamer-project/issues/29
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.
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
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
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/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.
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.
