This test takes 39 seconds on my machine even though it just runs
a couple of fakesrc num-buffers=2 ! fakesink pipelines. Most of
the cpu seems to be spent in libz, related to stack trace management.
Use stack-traces-flags=none instead of stack-traces-flags=full
until a better solution can be found. Might warrant more
investigation in any case..
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/503>
This is a follow up to review comments in !297
+ The posting of the buffering message in READY_TO_PAUSED isn't
needed, removing it made the test fail, but the correct fix
was simply to link elements together
+ Move code to relock the queue and set last_posted_buffering_percent
and percent_changed inside the buffering_post_lock in create_write().
This makes locking consistent with post_buffering()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
This fixes a bug that occurs when an attempt is made to post a buffering
message before the queue2 was assigned a bus. One common situation where
this happens is when the use-buffering property is set to TRUE before the
queue2 was added to a bin.
If the result of gst_element_post_message() is not checked, and the
aforementioned situation occurs, then last_posted_buffering_percent and
percent_changed will still be updated, as if posting the message succeeded.
Later attempts to post again will not do anything because the code then
assumes that a message with the same percentage was previously posted
successfully and posting again is redundant.
Updating these variables only if posting succeed and explicitely
posting a buffering message in the READY->PAUSED state change ensure that
a buffering message is posted as early as possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
gst-tester is a tool to launch `.validatetest` files with
TAP[0] compatible output and supporting missing `gst-validate`
application which means that it can be cleanly integrated with meson
test harness.
It allows us to use `gst-validate` to write integration tests in any
GStreamer repository keeping them as close as possible to the code. It
can simplify a lot test writing and reading and not having to go into
another repository to implement or run tests makes it more convenient to
use.
This also implements a stupid simple test to show how that works
[0] https://testanything.org/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/461>
This is needed for cross-compiling without a build machine compiler
available. The option was added in 0.54, but we only need this in
Cerbero and it doesn't affect older versions so it should be ok.
Will just cause a spurious warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/477>
To allow the refcounting tracer to work better. In childproxy/iterator
these might be plain GObjects but gst_object_unref() also works on them.
In other places where it is never GstObject, g_object_unref() is kept.
Even when pulling a new 64KB buffer from upstream, don't return
more data than was asked for in the pull_range() method and then
return less later, as that confused subclasses like h264parse.
Add a unit test that when a subclass asks for more data, it always
receives a larger buffer on the next iteration, never less.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/530
This new API allow resuming a task if it was paused, while leaving it to
stopped stated if it was stopped or not started yet. This new API can be
useful for callback driver workflow, where you basically want to pause and
resume the task when buffers are notified while avoiding the race with a
gst_task_stop() coming from another thread.
When running in pull mode (for e.g. mp3 reading),
baseparse currently reads 64KB from upstream, then mp3parse
consumes typically around 417/418 bytes of it. Then
on the next loop, it will read a full fresh 64KB again,
which is a big waste.
Fix the read loop to use the available cache buffer first
before going for more data, until the cache drops to < 1KB.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/518
What may happen is that during the course of processing a buffer,
all of the pads in a flow combiner may disappear. In this case, we
would return NOT_LINKED. Instead return whatever the input flow return
was.
In case the buffer is not writable, the parent (the BufferList) is not
removed before calling func. So if it is changed, the parent (the BufferList)
of the previous buffer should be removed after calling func.
Before that commit `{test, }` wouldn't be accepted as an array
because of the trailing coma, the commit fixes that.
At the same time, the code has been refactored to avoid special casing
the first element of the list, making `{,}` or `<,>` valid lists.
fixate() will return empty caps if it gets empty caps passed and assert
early if any caps are provided as there's no meaningful way of fixating
any caps.
truncate() and simplify() will return the input caps in case of
any/empty caps as before, but slightly optimized and as documented
behaviour.
Also add tests for this and a few other operations behaviour on
empty/any caps.
The clocksync element is a generic element that can be
placed in a pipeline to synchronise passing buffers to the
clock at that point. This is similar to 'identity sync=true',
but because it isn't GstBaseTransform-based, it can process
GstBufferLists without breaking them into separate GstBuffers
We do not have a way to know the format modifiers to use with string
functions provided by the system. `G_GUINT64_FORMAT` and other string
modifiers only work for glib string formatting functions. We cannot
use them for string functions provided by the stdlib. See:
https://developer.gnome.org/glib/stable/glib-Basic-Types.html#glib-Basic-Types.description
F.ex.:
```
../tools/gst-stats.c:921:11: error: too many arguments for format [-Werror=format-extra-args]
printf ("Number of Buffers passed: %" G_GUINT64_FORMAT "\n", num_buffers);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../tools/gst-stats.c:922:11: error: unknown conversion type character 'l' in format [-Werror=format=]
printf ("Number of Events sent: %" G_GUINT64_FORMAT "\n", num_events);
^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /builds/nirbheek/cerbero/cerbero-build/dist/windows_x86_64/include/glib-2.0/glib/gtypes.h:32,
from /builds/nirbheek/cerbero/cerbero-build/dist/windows_x86_64/include/glib-2.0/glib/galloca.h:32,
from /builds/nirbheek/cerbero/cerbero-build/dist/windows_x86_64/include/glib-2.0/glib.h:30,
from ../gst/gst.h:27,
from ../tools/tools.h:28,
from ../tools/gst-stats.c:30:
/builds/nirbheek/cerbero/cerbero-build/dist/windows_x86_64/lib/glib-2.0/include/glibconfig.h:69:28: note: format string is defined here
#define G_GUINT64_FORMAT "llu"
^
```
and
```
../tests/misc/netclock-replay.c: In function 'main':
../tests/misc/netclock-replay.c:98:23: error: unknown conversion type character 'l' in format [-Werror=format=]
if (sscanf (line, "%" G_GUINT64_FORMAT " %" G_GUINT64_FORMAT " %"
^~~
In file included from /builds/nirbheek/cerbero/cerbero-build/dist/windows_x86/include/glib-2.0/glib/gtypes.h:32,
from /builds/nirbheek/cerbero/cerbero-build/dist/windows_x86/include/glib-2.0/glib/galloca.h:32,
from /builds/nirbheek/cerbero/cerbero-build/dist/windows_x86/include/glib-2.0/glib.h:30,
from ../tests/misc/../../libs/gst/net/gstntppacket.c:38,
from ../tests/misc/netclock-replay.c:31:
/builds/nirbheek/cerbero/cerbero-build/dist/windows_x86/lib/glib-2.0/include/glibconfig.h:69:28: note: format string is defined here
#define G_GUINT64_FORMAT "llu"
^
```
This is needed for upgrading glib inside Cerbero which builds with
`-Werror` on Windows:
https://gitlab.freedesktop.org/gstreamer/cerbero/merge_requests/419
Keep the ANY caps empty internally when appending and merging
caps/structures. Previously, an ANY caps could end up containing
internal structures, which could be fetched by the user, and gave the
caps a non-zero length.
Also, made sure that `gst_caps_set_features_simple` frees the features
if caps is empty.
Fixed gst_caps_is_strictly_equal() to take into account whether either of
the caps are ANY caps. Previously, two ANY caps could be considered not
strictly equal if one of them still contained some remnant *internal*
structure (this can happen if an ANY caps has emerged from an append or
merge operation). Also, an ANY caps with no remnant internal structures
was considered strictly equal to an EMPTY caps. Similarly, a non-ANY caps
was considered strictly equal to an ANY caps if its remnant internal
structures happened to match.
Also changed gst_caps_is_fixed to take into account that an ANY caps
should not be considered fixed even if it contains a single remnant
internal fixed structure. This affects gst_caps_is_equal(), which uses a
separate method if both caps are fixed. Previously, this meant that a
non-ANY fixed caps was considered equal to an ANY caps if it contained a
single matching remnant internal structure.
Added some tests for these two equality methods, which covers the above
examples, as well as asserts existing behaviour.
Fixes#496
If you're using a custom log handler, you had to reverse-engineer the
debug log format and create your own format function. Now, you can
call `gst_debug_log_get_line()` and it will return a string (without
ANSI escape color codes) representation instead.
This is useful in situations when you need to log the ordinary
gst_debug log to a resource that can't be opened as a `FILE` handle.
Also includes a test.
We now have GstTestClock-based tests that validate the same logic,
without inducing spurious timing failures / overly relying on sleeps.
Fixes: #346Fixes: #347Fixes: #348
Co-authored by: Thibault Saunier <tsaunier@igalia.com>
There was a case where we started waiting on the clock before setting
the clock time, leading to the wait succeeding instead of being late:
gsttestclock.c:1073:F:testclock:test_late_crank:0: '1 * GST_SECOND' (1000000000) is not equal to 'context.jitter' (-4000000000)
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/426
Co-authored by: Mathieu Duponchelle <mathieu@centricular.com>
A common use case of a dynamically built pipeline is that you want to
(conditionally) find a certain element, e.g. the `rtpbin`s in a
`uridecodebin`. If that element has a fixed name inside its parent bin
(and only has a single instance) this can be easily done by
`gst_bin_get_by_name()`.
If there are multiple instances of the element however, you can only use
`gst_bin_iterate_all_by_interface()`, but this doesn't work if you don't
have the specific `GType` (which is often the case, due to plugins being
dynamically loaded). As such, another fallback could be to use the
well-known name of the element's factory (in case of our example, this
is of course `"rtpbin"`).
Fixes#345
There were two causes for the flakiness, one much rarer than
the other.
The test sets up a source with a sometimes pad added during
the transition of a wrapper bin from READY to PAUSED.
It runs 4 iterations, the last of which makes it so the
negotiation fails.
In that case, the intention as correctly presented by the following
comment:
/* [..] ie, the pipeline should create ok but fail to change state */
However the implementation of run_delayed_test was neither calling
get_state on the pipeline (it called it on the wrapper bin), nor
checking that the return of get_state was FAILURE (it actually
checked that it was not).
This led to an obvious race condition, and was fixed by calling
get_state on the pipeline, then checking that in this specific
case (expect_link == FALSE), the state change has actually failed.
The second, rarer race condition is at set_state time. When we
don't expect the link to succeed, the return of set_state may
either be FAILURE or ASYNC, depending on timing. This was fixed
by taking expect_link into account when checking the return value
of set_state.
Co-authored by: Thibault Saunier <tsaunier@igalia.com>
And change it to do nothing at all.
As debug categories don't use reference counting and they can be
retrieved from anywhere at any time by name, it is fundamentally unsafe
to free them at any point in time except for right before the end of the
process.
No code apart from a unit test seems to be currently using the function,
so deprecate it and also change it to do nothing at all.
Needs a valgrind suppression for:
==11119== Warning: invalid file descriptor -1 in syscall close()
==11119== Warning: invalid file descriptor -1 in syscall close()
==11119== Syscall param write(buf) points to uninitialised byte(s)
==11119== at 0x4C4AFAD: syscall (in /usr/lib64/libc-2.29.so)
==11119== by 0x4E70DF9: write_validate (Ginit.c:112)
==11119== by 0x4E70DF9: UnknownInlinedFun (Ginit.c:148)
==11119== by 0x4E70DF9: mincore_validate (Ginit.c:131)
==11119== by 0x4E70CC3: UnknownInlinedFun (Ginit.c:208)
==11119== by 0x4E70CC3: access_mem (Ginit.c:242)
==11119== by 0x4E75536: UnknownInlinedFun (libunwind_i.h:168)
==11119== by 0x4E75536: apply_reg_state (Gparser.c:863)
==11119== by 0x4E75A71: _ULx86_64_dwarf_step (Gparser.c:952)
==11119== by 0x4E71BD3: _ULx86_64_step (Gstep.c:71)
==11119== by 0x48BAF47: generate_unwind_trace (gstinfo.c:2726)
==11119== by 0x48BC92E: gst_debug_get_stack_trace (gstinfo.c:2908)
==11119== by 0x49B2BB2: handle_object_created.part.0 (gstleaks.c:384)
==11119== by 0x488134E: gst_object_constructed (gstobject.c:141)
==11119== by 0x49EC61B: g_object_new_internal (gobject.c:1845)
==11119== by 0x49EE347: g_object_new_valist (gobject.c:2128)
==11119== by 0x49EE69C: g_object_new (gobject.c:1648)
==11119== by 0x48CA59D: gst_pad_new_from_template (gstpad.c:867)
==11119== by 0x68C209E: gst_base_src_init (gstbasesrc.c:454)
==11119== by 0x4A0A0C3: g_type_create_instance (gtype.c:1858)
==11119== by 0x49EC42C: g_object_new_internal (gobject.c:1805)
==11119== by 0x49EDB14: g_object_new_with_properties (gobject.c:1973)
==11119== by 0x49EE6C0: g_object_new (gobject.c:1645)
==11119== by 0x48AF91A: gst_element_factory_create (gstelementfactory.c:372)
==11119== Address 0x1ffeffe000 is on thread 1's stack
==11119== in frame #6, created by generate_unwind_trace (gstinfo.c:2695)
Fixed in libunwind commit:
b256722d49
Needs a separate suppression for Debian because the callstack is
different there.
