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
Using a rate of 1.1 in the test is causing the test to
fail on 32-bit because ceil(1.1 * 10) can round to 12.
Instead use a rate 2.0 that can be expressed as floating
point number and doesn't trigger the problem.
https://bugzilla.gnome.org/show_bug.cgi?id=797154
Fixes a configure error with gst-build:
subprojects/gst-plugins-base/meson.build:235:2: ERROR: Fetched variable 'gst_check_dep' in the subproject 'gstreamer' is not a dependency object.
Fixes for gst_segment_position_from_running_time_full() when
converting running_times that precede the segment start (or
stop in a negative rate segment)
The return value was incorrectly negated in those cases.
Add some more unit test checks for those cases, and especially
for segments with offsets.
Otherwise it's not guaranteed that buffers are actually on disk after
pushing them, and reading the file via g_file_get_contents() might not
include them yet.
This reverts commit 11e0f451eb.
When pushing a sticky event out of a pad with a pad probe or pad offset,
those should not be applied to the event that is actually stored in the
event but only in the event sent downstream. The pad probe and pad
offsets are conceptually *after* the pad, added by external code and
should not affect any internal state of pads/elements.
Also storing the modified event has the side-effect that a re-sent event
would arrive with any previous modifications done by the same pad probe
again inside that pad probe, and it would have to check if its
modifications are already applied or not.
For sink pads and generally for events arriving in a pad, some further
changes are still needed and those are tracked in
https://bugzilla.gnome.org/show_bug.cgi?id=765049
In addition, the commit also had a refcounting problem with events,
causing already destroyed events to be stored inside pads.
Previously gst_buffer_list_foreach() could modify (drop or replace)
buffers in non-writable lists, which could cause all kinds of problems
if other code also has a reference to the list and assumes that it stays
the same.
https://bugzilla.gnome.org/show_bug.cgi?id=796692
gst_buffer_list_new_sized(0) will cause an underflow in a calculation
which then makes it try to allocate huge amounts of memory, which
may lead to aborts.
https://bugzilla.gnome.org/show_bug.cgi?id=795758
In the case where the user sets a new padprobeinfo->data in a probe
where the data is a sticky event, the new sticky event should be automatically
sticked on the probed pad.
https://bugzilla.gnome.org/show_bug.cgi?id=795330
Remove unneeded reapplication of patterns. Besides being
superfluous (gst_debug_reset_threshold already applies
patterns) it was also wrong and didn't stop checking patterns
after the first match (broken in 67e9d139).
Also fix up unit test which checked for the wrong order.
https://bugzilla.gnome.org/show_bug.cgi?id=794717
The queue gets filled by the tail, so a query will always be the tail
object, not the head object. Also add a _peek_tail_struct() method to the
GstQueueArray to enable looking at the tail.
With unit test to prevent future regression.
https://bugzilla.gnome.org/show_bug.cgi?id=762875
Position queries with GST_FORMAT_TIME are supposed to return stream
time.
gst_base_sink_get_position() estimates the current stream time on its
own instead of using gst_segment_to_stream_time(), but the algorithm
used was not taking segment.offset into account, resulting in invalid
values when this field was set to a non-zero value.
https://bugzilla.gnome.org/show_bug.cgi?id=792434
Occasionally this test would fail, especially if the system is under load,
because the position query would pick up the last position from the
last buffer timestamp which has a lower timestamp than what we're
looking for. The sleep is long enough, however. It's unclear to me why
exactly this happens but there seems to be some kind of scheduling
issue going on as the streaming thread floods the sink with buffers.
Let's throttle the fakesrc to 100 buffers per second and make the sink
sync to the clock to restore some sanity. It should be totally sufficient
to test what we want to test, and seems to make things reliable here.
Set up all ten pipelines and preroll them first, and only set
them to playing to run wild after they're all set up. If we set
them to PLAYING directly and let those threads run wild, then
it might take ages (many seconds) for the other pipelines to
even get up and running, especially on machines with only one
or two cores, and operating systems that suck at scheduling.
Now the fakesink test takes 19 secs instead of 71 secs on a
single-cpu windows machine.
Scale the number of threads used in the stress tests according to
the number of cores/cpus. We want some contention, but we also
don't want too much contention, as some operating systems are
better at handling 100 threads running wild on a single core
than others.
Add header with structure sizes for 64-bit windows as well.
They're almost the same as on Linux, but it looks like things
like padding unions get aligned slightly differently so there
are a handful of differences:
sizeof(GstGhostPad) is 528, expected 536
sizeof(GstPad) is 512, expected 520
sizeof(GstPadProbeInfo) is 64, expected 72
sizeof(GstProxyPad) is 520, expected 528
