These can be passed to gst_type_mark_as_plugin_api, to inform
plugin cache generation.
For now a single flag is specified, "IGNORE_ENUM_MEMBERS", it
can be used for dynamically generated enums to avoid documenting
environment-specific enumeration members. An example is
GstX265EncTune.
Since those are using the clock for sync, they need to also
provide a clock for good measure. The reason is that even if
downstream elements provide a clock, we don't want to have
that clock selected because it might not be running yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/509>
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.
The offset in gst_buffer_resize() is additive. So to move back the
offset to zero, we need to pass the opposite of the current offset. This
was raised through the related unit test failingon 32bit as on 64bit
the alignment padding was enough to hide the issue. The test was
modified to also fail on 64bit. This patch will remove spurious
assertions like:
assertion 'bufmax >= bufoffs + offset + size' failed
Fixes#316
At the moment, we can only use crank if the pending entry is in the
future. This patch leaves the clock time to the same point if the
pending entry was in the past. This still execute a single entry. This
will be needed for the jitterbuffer, since as soon as we stop waking up
the jitterbuffer when the timer is reschedule later, we may endup with
such case in the unit tests.
Related to #608
Instead of tracking "pending_flush_*" on the pads and the
aggregator, we now simply track the last seqnum for flush start
and flush stop events on the pads, and use it to determine whether
we should enter or exit our flushing state.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/977
This means we can use some newer features and get rid of some
boilerplate code using the `G_DECLARE_*` macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
Before GST_PAD_PROBE_HANDLED was introduced, we had to handle the case
where some probes would reset the probe info data field to NULL. This would
be considered an invalid use-case.
But with GST_PAD_PROBE_HANDLED it is totally fine to reset that, since
the probe has "handled" it.
When performing a key unit trickmode seek, it may be useful to
specify a minimum interval between the output frames, either
in very high rate cases, or as a protection against streams
that may contain an overly large amount of key frames.
One use case is ONVIF Section 6.5.3:
<https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf>
Other gstreamer repositories have their own valgrind suppression file
directly in the repository.
Add a suppression file to the core gstreamer repository too, this makes
it easier to use it with gst-build which does not check out the common
module.
This is also a little step towards the removal of the common submodule.
NOTE: the added file is the latest version from the "common" repository
but it has been renamed from gst.supp to gstreamer.supp for symmetry
with the suppression files in the other repositories.
Since elements_fdsrc.test_num_buffers uses blocking pipe on Windows,
the test will never be finished. But emulating non-blocking fd without
win32 APIs on Windows is a little tricky.
For metas where order might be significant if multiple metas are
attached to the same buffer, so store a sequence number with the
meta when adding it to the buffer. This allows users of the meta
to make sure metas are processed in the right order.
We need a 64-bit integer for the sequence number here in the API,
a 32-bit one might overflow too easily with high packet/buffer
rates. We could do it rtp-seqnum style of course, but that's a
bit of a pain.
We could also make it so that gst_buffer_add_meta() just keeps metas in
order or rely on the order we add the metas in, but that seems too
fragile overall, when buffers (incl. metas) get merged or split.
Also add a compare function for easier sorting.
We store the seqnum in the MetaItem struct here and not in the
GstMeta struct since there's no padding in the GstMeta struct.
We could add a private struct to GstMeta before the start of
GstMeta, but that's what MetaItem effectively is implementation-
wise. We can still change this later if we want, since it's all
private.
Fixes#262
gstharness.c: Use G_GSIZE_FORMAT instead of hard-coding %zu
error: unknown conversion type character 'z' in format [-Werror=format]
gst-inspect.c: GPid is void* on non-UNIX, and we only use it on UNIX
error: initialization makes pointer from integer without a cast [-Werror]
gstmeta.c: Use and then discard value
error: value computed is not used [-Werror=unused-value]
With this, gstreamer builds with -Werror on MinGW
While extremelly rare, time and gst_date_time_new_* will have
diff values and potentially trigger an assertion. Thus move
the calls as closely together as possible to mitigate this.
We have to ensure that all background threads from thread pools are shut
down, or otherwise they might not have had a chance yet to drop their
last reference to the pipeline and then the assertion for a reference
count of 1 on the pipeline fails.
Otherwise it can easily happen that the pad is destroyed before the
thread disappears, as happened sometimes in the test_pad_probe_block_add_remove
test where joining of the thread was done *after* the pad was unreffed
and destroyed.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/339
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.
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.
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
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.
If a segment has stop == -1, then gst_segment_to_running_time()
would refuse to calculate a running time for negative rates,
but gst_segment_do_seek() allows this scenario and uses a
valid duration for calculations.
Make the 2 functions consistent by using any configured duration
to calculate a running time too in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=796559
